[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 08 Apr 2012 00:54:57 +0200
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux)
Andy Wingo <address@hidden> skribis:
> 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
> are doing.
> 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?
I think so, and with a caveat in the manual.
Thanks for your patience. :-)