On Fri, Jun 05, 2009 at 11:04:18PM +0100, James Mansion wrote: <snip> > 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?
Well, one point is that posix_spawn() isn't portable. It's not available in OpenBSD, for instance; nor does it appear available in NetBSD. Another point is that other systems--like Linux (and perhaps every system _but_ Solaris)--put more emphasis on guaranteeing the safety of those corner cases rather than offloading the effort to the developer; I'd put money down that in 10 years all the uncertainty regarding threads and the remainder of the unspecified behavior wrt POSIX interfaces will have evaporated. Mostly the issue is that POSIX is meant to follow, not lead, in application design (notwithstanding the POSIX threading interface itself). And though there's ample example to follow, big players like Solaris prefer to drag their feet, and they tend to be rather incorrigible. Though, the only practical question, I suppose, is whether supporting the manifestly non-portable posix_spawn() interface is more or less work than not using it. And perhaps ultimately it is preferable to use posix_spawn(). _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
