Ok, so I've found that using the -V0 RTS flag to turn off the RTS clock (and associated signals) makes the code run fine with -threaded. I'm still digging through the implications of that, though. Has some behavior here changed in 7.4.1?
Mike Craig On Tue, Feb 14, 2012 at 3:54 PM, Michael Craig <mks...@gmail.com> wrote: > Hi all, > > I'm debugging an issue with multithreading and FFI calls in 7.4.1. The > code in question is the zeromq3-haskell library, which provides an FFI > binding to ZeroMQ. > > A little background: ZeroMQ gives the programmer "contexts" and "sockets". > Contexts are thread-safe and generally used one-per-process, but sockets > and not thread-safe so they're generally used one-per-thread. > > Have a look at the code in this gist: https://gist.github.com/1829190It's > just a server that prints requests and replies with "Hello", and a > client that sends the requests ["1", "2", ..., "10"] and prints the > responses. > > Despite the fact that ZMQ sockets are not thread-safe, it was possible to > compile and run this code with -threaded under 7.0.4. Using MVars or some > other locking mechanism, it was even possible to use the same socket from > multiple parallel threads. (As long as the socket was not actually used in > parallel by multiple threads, all was well.) In 7.4.1, the code will only > run if compiled without -threaded. With -threaded, it croaks with an > "operation on non-socket" error, which generally refers to a socket that's > either been closed or > > I've dug through the code in zeromq3-haskell and haven't found anything > suspicious looking. Before I go digging into libzmq itself, can somebody > assure me that nothing has changed in 7.4.1 with regard to -threaded or the > FFI that might cause this breakage? > > Cheers, > Mike Craig > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
