Steven McCoy wrote: > On 8 February 2010 17:41, Pavel Gushcha <[email protected] > <mailto:[email protected]>> wrote: > > Sometimes my multithreaded application is crashed while creating > sockets. I wrote simple test (attached) that illustrates the problem. > > Backtrace is following: > > #0 0x0000003b2fa81074 in ?? () from /lib/libc.so.6 > #1 0x0000003b2fa7f47a in memmove () from /lib/libc.so.6 > #2 0x00007f7b15b3d063 in std::vector<zmq2::socket_base_t*, > std::allocator<zmq2::socket_base_t*> > >::_M_insert_aux(__gnu_cxx::__normal_iterator<zmq2::socket_base_t**, > std::vector<zmq2::socket_base_t*, std::allocator<zmq2::socket_base_t*> > > >, zmq2::socket_base_t* const&) () from /usr/lib/libzmq.so.0 > > > Adding the new socket is an STL vector underneath and is not > thread-safe, which is a bit strange considering every other part of > create_socket is locked,
> socket_base_t *s = thread->create_socket (type_); The point is that 'thread' (zmq::app_thread_t) is 0MQ context associated with the OS thread we are running in. Thus, we should never access the same instance from two different OS threads. That's why there is no locking there. Btw, I've been able to reproduce the problem. What I've found so far is that occasionally, single zmq::app_thread_t is associated with two different OS threads - which shouldn't happen. I'm investigating further... Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
