[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 06 Apr 2012 11:30:13 -0700
Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
An ongoing discussion...
On Tue 27 Mar 2012 08:54, address@hidden (Ludovic Courtès) writes:
> Andy Wingo <address@hidden> skribis:
>> On Wed 21 Mar 2012 22:26, address@hidden (Ludovic Courtès) writes:
>>> What about adding a big fat warning in the doc about use of
>>> ‘primitive-fork’ in a multi-threaded program?
>> Sure. WDYT about a warning at runtime as well? (I assume you still
>> don't like the current master behavior of throwing an exception if other
>> threads are running?)
> I agree that ‘primitive-fork’ has a number of important shortcomings.
> I’m not convinced that anything needs to be done in the code itself,
> though. It’s just as harmful as ‘pointer->procedure’, in a way.
Indeed. One more point though, not to totally drive this discussion
into the ground: primitive-fork is unlike pointer->procedure in that its
correctness depends on global conditions rather than local conditions.
If I load up a library and dlsym an address, and I believe that the
library has some kind of interface stability, then using
pointer->procedure is correct -- independent of what other Guile modules
Whereas, the correctness of using primitive-fork in a module depends on
what other modules do. Even if your module that uses primitive-fork
doesn't interact with anything else, it suddenly becomes incorrect if
the user loads up some threads-using library, like an asynchronous DNS
resolver implemented using getaddrinfo and thread-pools.
If other threads are active, I think primitive-fork should raise an
error. But if you think warnings are the way to go, I'm OK with that
too. Do you still think warnings are the right answer?
> Yes, so internal threads could be handled specially. It seems the
> signal thread already gets restarted magically, for instance, thanks to
> the various scm_i_ensure_signal_delivery_thread calls.
Cool, we should add some tests that this works. I think it needs a
little implementation help currently. I'll take a look.
- Re: wip-threads-and-fork,
Andy Wingo <=