Re: [zeromq-dev] thread safe sockets and ZMQ_FD
Eventually the idea is to create epoll like API (zpoll?) to be used when polling on multiple sockets (which will create one file descriptor for the zpoll object) and to stop using the zmq_poll (only relevant for thread safe sockets). Example of the API: void* zmq_zpoll(); int zmq_zpoll_close(void* zpoll); int zmq_zpoll_add_socket(void* zpoll, void* s, zpoll_event* event); int zmq_zpoll_remove_socket(void* zpoll, void* s); int zmq_zpoll_add_fd(void* zpoll, int fd, zpoll_event* event); // for native file descriptor int zmq_zpoll_remove_fd(void* zpoll, int fd, zpoll_event* event); int zmq_zpoll_wait(void* zpoll, int timeout, zpoll_event* event); On Sun, Feb 22, 2015 at 3:19 PM, Joe McIlvain joe.eli@gmail.com wrote: I thought one of the major motivations for sharing a socket among threads was to avoid the (anti-)pattern of creating a socket for each request in a multithreaded environment and worrying about running out of file descriptors. It sounds like this new strategy would avoid allocations of more zmq socket structures, but still carry the same risks of file descriptor sprawl and possible exhaustion. Also if a signaller is created on each call to zmq_poll, what is the plan for how these FDs might be garbage collected so that you don't run out of FDs just from calling zmq_poll too many times (even from the same thread)? On Sat, Feb 21, 2015 at 9:27 AM, Doron Somech somdo...@gmail.com wrote: The one need to dispose it. My plan was to support zmq_poll by create signaler on each call. On Feb 21, 2015 6:21 PM, Thomas Rodgers rodg...@twrodgers.com wrote: I will hold off until you've fleshed out those details, but it sounds like the API for getting the signaling FD will be different from what everything else uses currently, which means there will be a class of socket types that I will need to special case to support in my bindings. Is there anyway to just make that API get_sockopt() for ZMQ_FD but make the FD returned the 'new' signaling one? On Saturday, February 21, 2015, Doron Somech somdo...@gmail.com wrote: Currently the thread safe sockets doesn't support polling on multiple sockets as stated in the PR: https://github.com/zeromq/libzmq/pull/1349 I'm planning to solve that by epoll like API where you create a poll and then add sockets to it. The poll type will create a file descriptor that will be added to each of the associated thread safe sockets. The mailbox_safe type already ( https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have a method called add signaler which is actually a file descriptor. On Sat, Feb 21, 2015 at 5:27 PM, Thomas Rodgers rodg...@twrodgers.com wrote: It looks like the recently added code for supporting thread safe sockets does not support returning the signalling FD for a socket that is marked thread safe. How would these socket types be used in a polling reactor then? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
I thought one of the major motivations for sharing a socket among threads was to avoid the (anti-)pattern of creating a socket for each request in a multithreaded environment and worrying about running out of file descriptors. It sounds like this new strategy would avoid allocations of more zmq socket structures, but still carry the same risks of file descriptor sprawl and possible exhaustion. Also if a signaller is created on each call to zmq_poll, what is the plan for how these FDs might be garbage collected so that you don't run out of FDs just from calling zmq_poll too many times (even from the same thread)? On Sat, Feb 21, 2015 at 9:27 AM, Doron Somech somdo...@gmail.com wrote: The one need to dispose it. My plan was to support zmq_poll by create signaler on each call. On Feb 21, 2015 6:21 PM, Thomas Rodgers rodg...@twrodgers.com wrote: I will hold off until you've fleshed out those details, but it sounds like the API for getting the signaling FD will be different from what everything else uses currently, which means there will be a class of socket types that I will need to special case to support in my bindings. Is there anyway to just make that API get_sockopt() for ZMQ_FD but make the FD returned the 'new' signaling one? On Saturday, February 21, 2015, Doron Somech somdo...@gmail.com wrote: Currently the thread safe sockets doesn't support polling on multiple sockets as stated in the PR: https://github.com/zeromq/libzmq/pull/1349 I'm planning to solve that by epoll like API where you create a poll and then add sockets to it. The poll type will create a file descriptor that will be added to each of the associated thread safe sockets. The mailbox_safe type already ( https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have a method called add signaler which is actually a file descriptor. On Sat, Feb 21, 2015 at 5:27 PM, Thomas Rodgers rodg...@twrodgers.com wrote: It looks like the recently added code for supporting thread safe sockets does not support returning the signalling FD for a socket that is marked thread safe. How would these socket types be used in a polling reactor then? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] thread safe sockets and ZMQ_FD
It looks like the recently added code for supporting thread safe sockets does not support returning the signalling FD for a socket that is marked thread safe. How would these socket types be used in a polling reactor then? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
Specifically, something like epoll or kqueues? On Sat, Feb 21, 2015 at 9:27 AM, Thomas Rodgers rodg...@twrodgers.com wrote: It looks like the recently added code for supporting thread safe sockets does not support returning the signalling FD for a socket that is marked thread safe. How would these socket types be used in a polling reactor then? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
Currently the thread safe sockets doesn't support polling on multiple sockets as stated in the PR: https://github.com/zeromq/libzmq/pull/1349 I'm planning to solve that by epoll like API where you create a poll and then add sockets to it. The poll type will create a file descriptor that will be added to each of the associated thread safe sockets. The mailbox_safe type already ( https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have a method called add signaler which is actually a file descriptor. On Sat, Feb 21, 2015 at 5:27 PM, Thomas Rodgers rodg...@twrodgers.com wrote: It looks like the recently added code for supporting thread safe sockets does not support returning the signalling FD for a socket that is marked thread safe. How would these socket types be used in a polling reactor then? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
You will be able to create a signaler which is a file descriptor, associate it with the socket and add it to the epoll or kqueue On Sat, Feb 21, 2015 at 5:32 PM, Thomas Rodgers rodg...@twrodgers.com wrote: Specifically, something like epoll or kqueues? On Sat, Feb 21, 2015 at 9:27 AM, Thomas Rodgers rodg...@twrodgers.com wrote: It looks like the recently added code for supporting thread safe sockets does not support returning the signalling FD for a socket that is marked thread safe. How would these socket types be used in a polling reactor then? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
I will hold off until you've fleshed out those details, but it sounds like the API for getting the signaling FD will be different from what everything else uses currently, which means there will be a class of socket types that I will need to special case to support in my bindings. Is there anyway to just make that API get_sockopt() for ZMQ_FD but make the FD returned the 'new' signaling one? On Saturday, February 21, 2015, Doron Somech somdo...@gmail.com wrote: Currently the thread safe sockets doesn't support polling on multiple sockets as stated in the PR: https://github.com/zeromq/libzmq/pull/1349 I'm planning to solve that by epoll like API where you create a poll and then add sockets to it. The poll type will create a file descriptor that will be added to each of the associated thread safe sockets. The mailbox_safe type already ( https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have a method called add signaler which is actually a file descriptor. On Sat, Feb 21, 2015 at 5:27 PM, Thomas Rodgers rodg...@twrodgers.com javascript:_e(%7B%7D,'cvml','rodg...@twrodgers.com'); wrote: It looks like the recently added code for supporting thread safe sockets does not support returning the signalling FD for a socket that is marked thread safe. How would these socket types be used in a polling reactor then? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org'); http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
s/comdition/condition/ On Sat, Feb 21, 2015 at 10:45 AM, Thomas Rodgers rodg...@twrodgers.com wrote: Which all brings us to my next question - Can we just move on to -std=c++11 for future libzmq versions? The big 3 compilers (well mostly, Microsoft still presents a few issues) support C++11 at this point. Many of the issues below would just 'go away' with the use of std::mutex, std::unique_lock, and std::comdition_variable. On Saturday, February 21, 2015, Bjorn Reese bre...@mail1.stofanet.dk wrote: On 02/21/2015 04:44 PM, Doron Somech wrote: (https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have I had a quick look at this class... The workaround in the destructor is not thread-safe. Another thread may enter and wait between the sync-unlock() and the end of the destructor scope. You need to add a state variable to prevent this from happening. Furthermore, if another thread is waiting on the condition variable, then the mutex is unlocked while it is waiting. You need to notify (broadcast) the condition variable to wake up the other thread and get it out of the class. You will most likely need to to add a reference count to keep track of how many pending threads are waiting in order to know when it is safe to exit the destructor. The use of sync-lock() and sync-unlock() is not exception safe. I suggest that you use a scoped lock instead of the explicit calls. Read this for inspiration: http://en.cppreference.com/w/cpp/thread/unique_lock The code does not handle spurious wakeups from the condition variable. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
Destroying a socket is still not thread safe, so the user still need to synchronize that On Feb 21, 2015 6:36 PM, Bjorn Reese bre...@mail1.stofanet.dk wrote: On 02/21/2015 04:44 PM, Doron Somech wrote: (https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have I had a quick look at this class... The workaround in the destructor is not thread-safe. Another thread may enter and wait between the sync-unlock() and the end of the destructor scope. You need to add a state variable to prevent this from happening. Furthermore, if another thread is waiting on the condition variable, then the mutex is unlocked while it is waiting. You need to notify (broadcast) the condition variable to wake up the other thread and get it out of the class. You will most likely need to to add a reference count to keep track of how many pending threads are waiting in order to know when it is safe to exit the destructor. The use of sync-lock() and sync-unlock() is not exception safe. I suggest that you use a scoped lock instead of the explicit calls. Read this for inspiration: http://en.cppreference.com/w/cpp/thread/unique_lock The code does not handle spurious wakeups from the condition variable. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
On Sat, Feb 21, 2015 at 5:45 PM, Thomas Rodgers rodg...@twrodgers.com wrote: Can we just move on to -std=c++11 for future libzmq versions? The big 3 compilers (well mostly, Microsoft still presents a few issues) support C++11 at this point. I'd guess Yes, though it's worth asking the list. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
The one need to dispose it. My plan was to support zmq_poll by create signaler on each call. On Feb 21, 2015 6:21 PM, Thomas Rodgers rodg...@twrodgers.com wrote: I will hold off until you've fleshed out those details, but it sounds like the API for getting the signaling FD will be different from what everything else uses currently, which means there will be a class of socket types that I will need to special case to support in my bindings. Is there anyway to just make that API get_sockopt() for ZMQ_FD but make the FD returned the 'new' signaling one? On Saturday, February 21, 2015, Doron Somech somdo...@gmail.com wrote: Currently the thread safe sockets doesn't support polling on multiple sockets as stated in the PR: https://github.com/zeromq/libzmq/pull/1349 I'm planning to solve that by epoll like API where you create a poll and then add sockets to it. The poll type will create a file descriptor that will be added to each of the associated thread safe sockets. The mailbox_safe type already ( https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have a method called add signaler which is actually a file descriptor. On Sat, Feb 21, 2015 at 5:27 PM, Thomas Rodgers rodg...@twrodgers.com wrote: It looks like the recently added code for supporting thread safe sockets does not support returning the signalling FD for a socket that is marked thread safe. How would these socket types be used in a polling reactor then? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
On 02/21/2015 04:44 PM, Doron Somech wrote: (https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have I had a quick look at this class... The workaround in the destructor is not thread-safe. Another thread may enter and wait between the sync-unlock() and the end of the destructor scope. You need to add a state variable to prevent this from happening. Furthermore, if another thread is waiting on the condition variable, then the mutex is unlocked while it is waiting. You need to notify (broadcast) the condition variable to wake up the other thread and get it out of the class. You will most likely need to to add a reference count to keep track of how many pending threads are waiting in order to know when it is safe to exit the destructor. The use of sync-lock() and sync-unlock() is not exception safe. I suggest that you use a scoped lock instead of the explicit calls. Read this for inspiration: http://en.cppreference.com/w/cpp/thread/unique_lock The code does not handle spurious wakeups from the condition variable. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
Which all brings us to my next question - Can we just move on to -std=c++11 for future libzmq versions? The big 3 compilers (well mostly, Microsoft still presents a few issues) support C++11 at this point. Many of the issues below would just 'go away' with the use of std::mutex, std::unique_lock, and std::comdition_variable. On Saturday, February 21, 2015, Bjorn Reese bre...@mail1.stofanet.dk wrote: On 02/21/2015 04:44 PM, Doron Somech wrote: (https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have I had a quick look at this class... The workaround in the destructor is not thread-safe. Another thread may enter and wait between the sync-unlock() and the end of the destructor scope. You need to add a state variable to prevent this from happening. Furthermore, if another thread is waiting on the condition variable, then the mutex is unlocked while it is waiting. You need to notify (broadcast) the condition variable to wake up the other thread and get it out of the class. You will most likely need to to add a reference count to keep track of how many pending threads are waiting in order to know when it is safe to exit the destructor. The use of sync-lock() and sync-unlock() is not exception safe. I suggest that you use a scoped lock instead of the explicit calls. Read this for inspiration: http://en.cppreference.com/w/cpp/thread/unique_lock The code does not handle spurious wakeups from the condition variable. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org javascript:; http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
in addition to not being exception safe, all of the explicit entry and early exit from the mutex is a fully loaded footgun for some future developer working on this code. RAII is a core idiom of C++ and scoped locks/guards are the only sensible and safe way to write this sort of code so that will be both exception safe and have a chance of not biting someone down the road. Also, std::condition_variable has explicit support for handling spurious wakeups. see - http://en.cppreference.com/w/cpp/thread/condition_variable/wait The second variant of wait() takes a predicate which can be used to ignore spurious wakeups. On Sat, Feb 21, 2015 at 10:51 AM, Thomas Rodgers rodg...@twrodgers.com wrote: s/comdition/condition/ On Sat, Feb 21, 2015 at 10:45 AM, Thomas Rodgers rodg...@twrodgers.com wrote: Which all brings us to my next question - Can we just move on to -std=c++11 for future libzmq versions? The big 3 compilers (well mostly, Microsoft still presents a few issues) support C++11 at this point. Many of the issues below would just 'go away' with the use of std::mutex, std::unique_lock, and std::comdition_variable. On Saturday, February 21, 2015, Bjorn Reese bre...@mail1.stofanet.dk wrote: On 02/21/2015 04:44 PM, Doron Somech wrote: (https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have I had a quick look at this class... The workaround in the destructor is not thread-safe. Another thread may enter and wait between the sync-unlock() and the end of the destructor scope. You need to add a state variable to prevent this from happening. Furthermore, if another thread is waiting on the condition variable, then the mutex is unlocked while it is waiting. You need to notify (broadcast) the condition variable to wake up the other thread and get it out of the class. You will most likely need to to add a reference count to keep track of how many pending threads are waiting in order to know when it is safe to exit the destructor. The use of sync-lock() and sync-unlock() is not exception safe. I suggest that you use a scoped lock instead of the explicit calls. Read this for inspiration: http://en.cppreference.com/w/cpp/thread/unique_lock The code does not handle spurious wakeups from the condition variable. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
Hi all, Be careful with requiring C++11 constructs. Some environments may need to use older compilers. For example, building PyZMQ from source for Python 2.7 (and some early Python 3 releases) requires building with VS2008, which does not support C++11. Cheers, André On Sat, Feb 21, 2015 at 1:17 PM, Doron Somech somdo...@gmail.com wrote: Destroying a socket is still not thread safe, so the user still need to synchronize that On Feb 21, 2015 6:36 PM, Bjorn Reese bre...@mail1.stofanet.dk wrote: On 02/21/2015 04:44 PM, Doron Somech wrote: (https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have I had a quick look at this class... The workaround in the destructor is not thread-safe. Another thread may enter and wait between the sync-unlock() and the end of the destructor scope. You need to add a state variable to prevent this from happening. Furthermore, if another thread is waiting on the condition variable, then the mutex is unlocked while it is waiting. You need to notify (broadcast) the condition variable to wake up the other thread and get it out of the class. You will most likely need to to add a reference count to keep track of how many pending threads are waiting in order to know when it is safe to exit the destructor. The use of sync-lock() and sync-unlock() is not exception safe. I suggest that you use a scoped lock instead of the explicit calls. Read this for inspiration: http://en.cppreference.com/w/cpp/thread/unique_lock The code does not handle spurious wakeups from the condition variable. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
Why would these be not compile-able with newer versions of VC (I believe VS2008 Goes EOL in July of this year)? Note, changing the libzmq to build with -std=c++11 would not change the C89 compatibility of it's public API. On Saturday, February 21, 2015, André Caron andre.l.ca...@gmail.com wrote: Hi all, Be careful with requiring C++11 constructs. Some environments may need to use older compilers. For example, building PyZMQ from source for Python 2.7 (and some early Python 3 releases) requires building with VS2008, which does not support C++11. Cheers, André On Sat, Feb 21, 2015 at 1:17 PM, Doron Somech somdo...@gmail.com javascript:_e(%7B%7D,'cvml','somdo...@gmail.com'); wrote: Destroying a socket is still not thread safe, so the user still need to synchronize that On Feb 21, 2015 6:36 PM, Bjorn Reese bre...@mail1.stofanet.dk javascript:_e(%7B%7D,'cvml','bre...@mail1.stofanet.dk'); wrote: On 02/21/2015 04:44 PM, Doron Somech wrote: (https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have I had a quick look at this class... The workaround in the destructor is not thread-safe. Another thread may enter and wait between the sync-unlock() and the end of the destructor scope. You need to add a state variable to prevent this from happening. Furthermore, if another thread is waiting on the condition variable, then the mutex is unlocked while it is waiting. You need to notify (broadcast) the condition variable to wake up the other thread and get it out of the class. You will most likely need to to add a reference count to keep track of how many pending threads are waiting in order to know when it is safe to exit the destructor. The use of sync-lock() and sync-unlock() is not exception safe. I suggest that you use a scoped lock instead of the explicit calls. Read this for inspiration: http://en.cppreference.com/w/cpp/thread/unique_lock The code does not handle spurious wakeups from the condition variable. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org'); http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org'); http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread safe sockets and ZMQ_FD
You are right. I will change it to use scoped lock. On Sat, Feb 21, 2015 at 6:36 PM, Bjorn Reese bre...@mail1.stofanet.dk wrote: On 02/21/2015 04:44 PM, Doron Somech wrote: (https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have I had a quick look at this class... The workaround in the destructor is not thread-safe. Another thread may enter and wait between the sync-unlock() and the end of the destructor scope. You need to add a state variable to prevent this from happening. Furthermore, if another thread is waiting on the condition variable, then the mutex is unlocked while it is waiting. You need to notify (broadcast) the condition variable to wake up the other thread and get it out of the class. You will most likely need to to add a reference count to keep track of how many pending threads are waiting in order to know when it is safe to exit the destructor. The use of sync-lock() and sync-unlock() is not exception safe. I suggest that you use a scoped lock instead of the explicit calls. Read this for inspiration: http://en.cppreference.com/w/cpp/thread/unique_lock The code does not handle spurious wakeups from the condition variable. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
