William Ahern wrote:
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
Actually the rationale I meant was this:
https://sun.systemnews.com/articles/99/5/sw/16419
Sorry about that.
Do I need to produce an example? No. The standard says 'don't do it'
and that's that,
surely?
Most code that's threaded will expect the standards to be followed and
surely all the
gross ugliness necessary to unwind everything with pthread_atfork isn't
always there
and is unlikely to be bullet-proof.
What's the problem? You have the 'run in child' mechanism there for
Windows, so
use it in POSIX too and its job done, whether or not there are any
threads in play.
If you *know* you only have one thread then its fair game to do the old
thing, but
we're talking about a process that has regress_pthread in it.
Surely it used to be that as an app developer I was pretty much in
control of whether
my process was threaded, but now its increasingly hard to write
applications where that's
the case unless you are prepared to rebuild a lot of support libraries,
and its hardly
worth the effort any more. What's the point?
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
