You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Farid Zaripov <Fa...@kyiv.vdiweb.com> on 2006/11/09 17:00:55 UTC

Mt tests

  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.

  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. Another issue is that static and global variables
will not be initialized and will contain will the previous values.

  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?

Farid.

Re: Mt tests

Posted by Martin Sebor <se...@roguewave.com>.
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