Hey! Andy Wingo <wi...@pobox.com> skribis:
> On Tue 27 Mar 2012 08:54, l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo <wi...@pobox.com> skribis: >> >>> On Wed 21 Mar 2012 22:26, l...@gnu.org (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. Right. > 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. :-) Ludo’.
