Re: wip-threads-and-fork

[Ludovic Courtès]

Hi!

Andy Wingo <address@hidden> skribis:

> On Sun 26 Feb 2012 23:00, address@hidden (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’.