GC> But you can't know that this will be the case at the time that GC> fork() was called; the child might not call exec(). GC> If you get around the problem by overcommitting, then you are GC> left with a child process which can die suddenly just because it GC> wrote to one page too many. This isn't a good idea if you want to GC> write robust programs. This is exactly the situation on Linux 2.0.* (don't know for sure about 2.1.*), if I read the current discussion on the (german) de.comp.os.unix.discussion. GC> The solution is to provide a usable vfork(), i.e. one where you GC> can guarantee being able to perform a minimal set of useful GC> operations between the vfork() and the exec(). dup2() is an GC> obvious candidate; signal handling would also be pretty high on GC> the list. I would like to get more information on that idea (and on dup2), could you provide some (perhaps by private email) for reproduction in that current discussion. Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch." -- Anselm Lingnau in de.comp.os.unix.linux.misc