[zeromq-dev] context as global/static variable

[Daniel Krikun]

Further, I suspected there maybe a problem due to the singleton not being
thread-safe. Thus, I modified the code to something like this:

boost::mutex mutex_;
zmq::context_t* p_ = 0;

zmq::context_t& get_global_context()
{
       boost::mutex::scoped_lock(mutex_);
       if(p_ == 0)
            p_ = new zmq::context_t(1);

       return *p_;
}

Well, that worked fine, but apparently, context_t destructor is never
invoked (am I correct?). If, for example, I change p_ to some smart
pointer, like boost::shared_ptr, which will invoke ~context_t at program
shutdown, then the same problem appears.
I guess, there is some problem in calling ~context_t at program exit.
Ideas?

On Wed, May 9, 2012 at 12:39 PM, Daniel Krikun <krikun.daniel at gmail.com>wrote:

> Hello,
>
> I have some c++ code, that uses zeromq. In the code, I have a singleton
> wrapping zmq::context_t, like this:
>
> struct ctx_singleton
> {
>            zmq::context_t& instance()
>            {
>                  static zmq::context_t _ctx;
>                  return _ctx;
>            }
> };
>
> At application shutdown, I get an assertion failure:
>   Successful WSASTARTUP not yet perfromed (..\..\..\src\signaler.cpp:124)
>
> I suspected there was a problem w/ zmq::context_t having global storage,
> so I just take some zeromq sample and moved context definition from main
> into global scope, and yes, I yields the same failure. I looked at the
> stack trace, it seems that some socket/synch. mechanism is already disposed
> when zmq_term is invoked and thus the failure.
>
> I really would like to put zmq::context_t instance, just to make things
> easier, and not to pass the instance to all threads. Is there a possibility
> to do so?
>
> I'm using zeromq-2.1.11, visual studio 2008 on Windows XP sp3, 32-bit.
>
> Thanks,
>
> --
> Daniel Krikun
>
>


-- 
Daniel Krikun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120509/53b4d673/attachment.htm>