> > 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]