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
