[zeromq-dev] zmq::signaler_t::make_fdpair hangs application on crash

KIU Shueng Chuan nixchuan at gmail.com
Wed Nov 13 14:11:02 CET 2013


Which versions of Windows and ZeroMQ does it happen on? Does your
application open and close lots of ZeroMQ sockets? How about with libzmq
master?

Actually you could submit the change to mutex and port yourself?
On Nov 13, 2013 3:02 AM, "Felipe Farinon" <felipe.farinon at powersyslab.com>
wrote:

>  My application is hanging frequently in one co-worker's machine. Whenever
> I diagnose the machine, I see the event still set with no application
> running. I'm afraid that when the application ships the bug happens much
> more.
>
> We wouldn't be taking "one more port", just changingthe old one.
>
> Em 12/11/2013 10:52, KIU Shueng Chuan escreveu:
>
> I thought of the same thing before, port 5906 too. But I don't feel
> comfortable taking up one more port without some consensus. Maybe if there
> were more people reporting that their ZeroMQ applications (with heavy
> socket creation!) were hanging on Windows...
>
>  For now, I have modified signaler.cpp to not assert within the "critical
> section".
>
> https://github.com/zeromq/libzmq/commit/4a7f07a19ae226fe92c3c7320bd425f9a18d0c79
>
>
> On Mon, Nov 11, 2013 at 11:16 PM, Felipe Farinon <
> felipe.farinon at powersyslab.com> wrote:
>
>>  Maybe we could change signaler_port to another value and define that
>> port 5905 is protected by the Event and the new port (e.g. 5906) is
>> protected by Mutex. This way we don't need to check if the Event is present.
>>
>> Em 11/11/2013 11:16, Felipe Farinon escreveu:
>>
>> Ok.
>>
>> Seems reasonable to me and I think that a 4 seconds timeout is fine. The
>> only scenario where I could imagine that this would break is if some heavy
>> socket creation is going on and IFF the WaitForSingleObject wakeup order
>> for Events is not FIFO.
>>
>> Em 11/11/2013 11:02, KIU Shueng Chuan escreveu:
>>
>> Realistically, I think only bind, accept and connect have a chance of
>> failing. The rest of the asserts just test for programming errors. Accept
>> and connect are already handled. What's left is handling bind error.
>>
>>
>> _______________________________________________
>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
>
> _______________________________________________
> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131113/68df5968/attachment.html>


More information about the zeromq-dev mailing list