On Fri, Jun 05, 2009 at 10:19:46PM +0100, James Mansion wrote: > 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.
I'm as much a standards pendant as the next guy, but can you point out any implementation that forks threads (i.e. the fork'd process keeps the threads), or where otherwise forking (other than from a signal handler), actually creates issues? I even expect a positive response, and I think actually pointing them out would be productive. But the vfork() issue mentioned in the link is inconsequential in this case, for many reasons, not the least of which is because vfork() needn't be used. If there's memory pressure issue (if fork() fails where vfork() would exceed, there's no reason to believe the exec() wouldn't also fail in the same situation; indeed, there's more reason to think a successful fork() would ultimately fail because there wouldn't be as many shared pages; of course, neither process would be particularly big, anyhow). I don't refuse to use strlcpy() because it violates the C namespace--whereby "anything can happen". Even considering that Solaris' strlcpy() is not compatible w/ the OpenBSD's strlcpy(). > The number of system/library calls you can legally make in a threaded > application after a fork is very limited indeed. You can legally make all the same calls, the behavior just might not be well-defined. > >(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. > posix_spawn() isn't portable. There's portable (SUSv3) and then there's portable (not available in some widely used BSDs). Does your implementation have stpcpy() and stpncpy()? Those are in POSIX/SUSv3-2008, too. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
