OK, turns out that the culprit was that it was possible for the destructor of one of my classes to be called from a different thread than the constructor. There was a socket class member in that class, so the open and close on the socket could be called from different threads, which is a no-no.
I'd like to follow up with a question though. If anyone can help with this, that would be awesome! From the FAQ: For those situations where a dedicated socket per thread is infeasible, a socket may be shared if and only if each thread executes a full memory barrier before accessing the socket. Most languages support a Mutex or Spinlock which will execute the full memory barrier on your behalf. Now, from this, I take it that it would be correct (if not encouraged) to have thread A create a socket while holding a mutex, have thread B some time later call send() on the socket while holding the mutex, and then have thread A some time later call close() on the socket, also while holding the mutex? What about the following scenario? 1. Thread 1 locks mutex, creates socket, and never uses the socket again. 2. Thread 2 locks mutex, calls send(), and never uses the socket again. 3. Thread 3 locks mutex, and calls close() on the socket. Where all this rears its head for me is that I need to shut down a number of worker threads. I'm using the PUB/SUB pattern recommended in the guide, with the worker threads polling on the SUB to find out when they are supposed to go away. The problem is that I don't have a dedicated thread that ends up publishing the stop message; instead, the stop can be triggered by arbitrary application threads (of whose existence I don't even know). If I do the naive thing and just create the PUB socket from the calling thread at the time the stop message needs to be sent, I end up with the slow joiner problem. That problem goes away if I use inproc instead of ipc, but that's not really a clean solution because, in theory, the implementation of inproc could change in the future. I know, I could just keep a dedicated thread that creates the socket, sleeps, wakes up when the stop needs to be sent, does the send(), and then the close(). But that seems a bit heavy-weight, as does a solution where a dedicated thread listens for a stop message on an inproc PULL socket and then writes the stop message to the PUB socket (so I can avoid the slow joiner syndrome with ipc, and make sure that I bind() to the PUB before any subscribers connect to the SUB with the inproc transport). Thanks, Michi. On 2 Apr 2014, at 2:30 , Michi Henning <[email protected]> wrote: > Thanks Gonzalo (and Pieter and Andrew). I'll work on that and see what I can > come up with. > > Cheers, > > Michi.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
