incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: Mt tests
Date Fri, 10 Nov 2006 01:27:48 GMT
Farid Zaripov wrote:
>   The idea of the multithreaded tests is running of the self executable
> as another process with additional parameters.
> 
>   It is not a problem on windows because argv[0] is full path to the
> executable on MSVC. Even if it's not always true,
> the function GetModuleFileName() returns that path. On unix it is not
> guaranteed that argv[0] is full path to the executable.

Right. argv[0] can be anything, including "" or even 0.

> 
>   In the beginning I thought to use fork() to create a child copy of the
> process and call main() with new parameters and
> then call exit() with returned value from main(), but I not sure that is
> correct. 

It isn't. The language doesn't allow main() to be called.

> Another issue is that static and global variables
> will not be initialized and will contain will the previous values.

Right. That could also be a problem.

> 
>   I found that reading of the symlink /proc/self/exe is may return the
> path to the executable, but there is no strict guarantee of it.
> 
>   Whether there is a reliable way to get this path?

There are ways, but they're not portable or necessarily reliable.
On Linux you might be able to get the pathname under the /proc
filesystem (e.g., /proc/$$/exe looks like it's a symbolic link
pointing to the program's executable file on the disk). Solaris
also has a /proc filesystem (the /proc/$$/paths/a.out link points
to the executable file). On systems that don't expose this info
under an API (such as AIX) you might be able to use the ps command
(but the results may not be 100% reliable).

I think the simplest and most reliable way might be to hardcode
the pathname of the executable (or just BUILDDIR) into the program
itself and have it use it to exec itself.

Martin

Mime
View raw message