Hi! Andy Wingo <wi...@pobox.com> skribis:
> On Sun 26 Feb 2012 23:00, l...@gnu.org (Ludovic Courtès) writes: [...] >> When the only threads are the main thread >> and the signal thread, everything’s alright. For example, this works >> fine on GNU/Linux: >> >> (let ((p (primitive-fork))) >> (case p >> ((0) >> (sigaction SIGINT (lambda args >> (format #t "kid ~a got ~a~%" (getpid) args) >> (exit 0))) >> (let loop () (loop)) >> (exit 1)) >> (else >> (sleep 2) >> (kill p SIGINT) >> (format #t "killed ~a~%" p) >> (waitpid p)))) >> >> It works because the signal thread is stuck in a read(2) with no lock >> taken. > > "Works" ;-) It mostly works on GNU/Linux. But not all the time! Other > processes can send your thread signals -- indeed, one would expect that > it's for that reason that you installed a signal handler. If the > signal-handling thread wakes up and queues an async, it could be in the > middle of allocation, hold the alloc lock, and thereby prevent the child > from allocating anything. Or it could have the async mutex. That’s highly unlikely, but yes, it could happen. I still think that saying that “a guile built with threads […] should not call primitive-fork” is too strong, because again, it’s very, very unlikely to fail when (= 1 (length (all-threads))), GNU/Linux or not. Let’s not scare our users more than necessary. ;-) And perhaps it can be fixed in 2.0 based on what ‘wip-threads-and-fork’ provides, as discussed in another message. Thanks, Ludo’.
