[Haskell-cafe] Behavior of -threaded in GHC 7.4.1?

[Michael Craig]

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 <mkscrg at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120215/f1343565/attachment.htm>