Hi, Mathieu Othacehe <[email protected]> skribis:
>> To me, ideally this would be either multi-threaded or Fiberized. The >> latter would be more fruitful but what might be difficult is >> guile-simple-zmq integration with Fibers (but maybe not: zmq_getsockopt >> + ZMQ_FD lets us get the file descriptor of a socket). > > I would prefer the multi-threaded approach if possible. While the > concept of Fiber is nice it adds another layer of complexity and > instability to those programs which are already hard to debug. I guess it’s not black and white. Shared-state multithreading is an endless source of bugs, regardless of the language being used; message-passing (what Fibers is about) is more tractable. Sure Fibers can have bugs of its own (I’m well aware of that :-)) but at Fiber-using code can be simpler and less error-ridden than the equivalent shared-state code. Anyway, we’re not there yet. Can you remember the rationale for forking in remote-worker.scm, or do you think we might as well do it all in a single process? Thanks, Ludo’.
