William Ahern wrote:
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()
I think this:
http://www.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html says that it is de-jure portable, and systems that don't have it yet can be expected to get it in future. Granted some of the systems that you mention have dubious (at best) commitment to the actual standards as published; I don't know why you accuse Solaris of dragging its feet. The platforms you mention were also tardy implementing decent threading and aio support. OpenBSD still is. (And, I have to say, I trust the Solaris engineering team much more for this sort of detail than the Linux 'team' in particular, and I'd take FreeBSD's and NetBSD's development processes over Linux's too.) But no matter - I think that: - posix_spawn should be used if available - failing that, try to do async signal safe fork/exec and hope that similar dynamic loader issues don't bite Unless you can be sure that the process is single threaded and you really need a forked process for C-o-W state snapshot etc. I'm not going to argue that fork/vfork etc are necessarily valueless now or in the past - though its certainly the case that its necessity is a lot less than it was when I started (and I felt spoiled at the time since I had my own Sparc IPX and SunOS 4.1). In the case in point for running the regression tests, I can't see why there is a real need to do any address-space cloning - while it may have been 'not broke so don't fix it' and an easy way to pass the test parameters to the child, a need to implement an exec-and-pass-params-and-resources solution for Windows means that a single model can be used for both: it just needs to be the Windows one. Why maintain two mechanisms? Its just asking for one or other to suffer bitrot. James _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
