Heya :) An ongoing discussion...
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. 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. Cheers, Andy -- http://wingolog.org/
