> > 3) You cannot link to the pthreads library and still use fork, and
> David, you absolutely cannot link with pthreads and still use fork()!!!!
> It doesn't work except in a few very simplistic scenarios.
> -paul
What you are saying just doesn't make any sense. I agree that it is
difficult to use fork properly in a process that creates multiple threads.
But this has nothing whatsoever to do with linking with the pthreads library
nor with compiling your code multi-threaded.
You can write code that has multiple internal models, say one that uses
'fork' the way unthreaded processes normally do and one that uses
multiple-threads, and compile it using your platform's options for compiling
a multi-threaded process. You can then select at run time whether to create
threads or to call 'fork'.
On no platform that claims POSIX compliance will you have any problems at
all. The problem you are complaining about simply does not exist.
Yes, it's difficult to use 'fork' in a process that actually creates
multiple threads. But whether or not a process *creates* multiple threads is
not a compilation issue, it's a run time issue. So it can't possibly cause
you to need to compile two versions.
I defy you to show me any platform where 'fork' breaks just because you
specify multi-threaded compiler options or link to the threading library.
You can most certainly do:
int multi_threaded;
if(multi_threaded)
{
// some code that calls pthread_create
}
else
{
// some code that calls fork
}
And compile it multi-threaded and link it to the pthreads library and you
will have *NO* issues with 'fork'.
The issues you are talking about with 'fork' are all run-time issues. None
of them require compiling two copies of a library.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
