| bleachbot <bleachbot@httrack.com>: Jan 03 11:01PM +0100 |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 03 05:00PM On Fri, 02 Jan 2015 02:20:32 -0600 > child. However, there is no good way for the library to know that > (the application and other libraries may call fork() from multiple > places in parallel, some followed by exec, some not). I am not certain that you can use pthread_atfork() to do even that. David Butenhof, the author of the canonical "Programming with POSIX threads" and then member of the POSIX committee dealing with threads (he may still be, I don't know) pointed out some time ago that although the prepare handler and parent handler can call functions which are not async-signal-safe (provided fork() is not called in a signal handler), the child handler cannot because it executes in the new process: https://groups.google.com/forum/?_escaped_fragment_=msg/comp.programming.threads/ThHE32-vRsg/3j-YICgSQzoJ#!msg/comp.programming.threads/ThHE32-vRsg/3j-YICgSQzoJ https://groups.google.com/forum/?_escaped_fragment_=msg/comp.programming.threads/ThHE32-vRsg/_nZ7_8Ygt-0J#!msg/comp.programming.threads/ThHE32-vRsg/_nZ7_8Ygt-0J This means that the child handler cannot do anything as simple as call pthread_mutex_unlock() (let alone create new threads), because that is not async-signal-safe. All you can really use pthread_atfork() for is to use the prepare and parent handlers to put the program in a consistent state which both the parent and child processes are subsequently capable of recovering from (and in the case of the child, without calling non-async-signal-safe functions). This means that the rule that any fork() in a multi-threaded program should shortly thereafter be followed by an exec*() still generally applies. Presumably those who write servers which are both multi-threaded and spawn new server processes on demand are using windows, and windows allows that (and I do not know if it does or it does not); or they must be doing something very clever. Chris |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 03 02:29PM -0600 Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote in > Presumably those who write servers which are both multi-threaded > and spawn new server processes on demand are using windows, and > windows allows that (and I do not know if it does or it does not); Windows does not really have fork(). There is a function ZwCreateProcess() in the POSIX subsystem of Windows which ought to be capable of that, but it seems this is underdocumented and not easily usable, if at all. And the POSIX subsystem is ditched anyway in last Windows versions. Instead of fork(), there is CreateProcess() which always starts a new process from scratch and is pretty heavyweight. One can emulate fork(Cygwin does this), but this is even more heavyweight (involves lots of twiddling with the new process to copy over all the memory and state). Cheers Paavo |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment