Nick Mathewson wrote:
To me, the Windows code is the special case: Emulating it on Unix
would require replacing CreateProcess with an explicit or implicit
fork-and-exec() pair... but once we have forked, there is not really
any point in calling exec(), since we are already in an isolated
process, which was what we wanted.
If any API has created a thread implicitly then you're in big trouble
and it can go wrong
for you if any additional thread is in use. And compiling with the
threaded settings
makes that fair game.
The number of system/library calls you can legally make in a threaded
application
after a fork is very limited indeed.
(While some Windows people consider Unix's fork() call a mistake, Unix
people generally consider CreateProcess() to be an odd hybrid of
fork(), exec*(), and a few other syscalls. _De gustibus non est
disputandum_, I suppose.)
Yeah, right, hence posix_spawn.
I know you're trying to be helpful and you can't possibly know what UNIX
experience I
have.
It used to be reasonable to concentrate on fork and vfork as appropriate but
the issues with async signal safety and the rational for posix_spawn
mean that
its much, much safer to exec than to make any assumptions about whether
you can safely fork and use arbitrary code.
The most accessible rationale for posix_spawn is probably here:
http://developers.sun.com/solaris/articles/subprocess/subprocess.html
There, now we can both be condescending. ;-)
James
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
