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

[Felipe Farinon]

I would feel a lot more safe if I added that timeout to 4 seconds :) . 
That's not so bad since this is a situation that shouldnt happen so 
often. We can even decrease the probability of this situation by 
properly handling the errors occured in the functions between 
CreateEvent and SetEvent, not just crashing the application with the 
Event still set.

Em 09/11/2013 12:29, KIU Shueng Chuan escreveu:
> The problem with simply switching to using Mutex is that it would 
> break compatibility with older versions using an Event.
>
> I tried coding a backwards compatible version.
> https://github.com/pijyoi/libzmq/blob/eventhang/src/signaler.cpp
> It first locks using a Mutex, then locks again using the old Event 
> mechanism for backwards compatibility. However, if locking using the 
> Event times out (1 sec), it assumes that the Event mechanism has hung 
> and proceeds as though it had acquired the Event (and will release the 
> Event at the end)
>
> I am not so sure if the assumption that a 1 sec timeout means that it 
> has hung is valid in all situations though.
>
>
> On Sat, Nov 9, 2013 at 5:36 PM, Pieter Hintjens <ph at imatix.com 
> <mailto:ph at imatix.com>> wrote:
>
>     Hi Felipe,
>
>     Can you reproduce the case? If you can make a patch and test case, we
>     can backport this to 4.0 and 3.2 stable if it applies there.
>
>     -Pieter
>
>     On Fri, Nov 8, 2013 at 8:46 PM, Felipe Farinon
>     <felipe.farinon at powersyslab.com
>     <mailto:felipe.farinon at powersyslab.com>> wrote:
>     > In windows, the code that creates a mutual exclusive section
>     uses the
>     > 'Event' mechanism.
>     >
>     >      HANDLE sync = CreateEvent (&sa, FALSE, TRUE, TEXT
>     > ("Global\\zmq-signaler-port-sync"));
>     >      if (sync == NULL && GetLastError () == ERROR_ACCESS_DENIED)
>     >        sync = OpenEvent (SYNCHRONIZE | EVENT_MODIFY_STATE,
>     FALSE, TEXT
>     > ("Global\\zmq-signaler-port-sync"));
>     >
>     >      win_assert (sync != NULL);
>     >
>     >      //  Enter the critical section.
>     >      DWORD dwrc = WaitForSingleObject (sync, INFINITE);
>     >      zmq_assert (dwrc == WAIT_OBJECT_0);
>     >
>     >      // Some code here...
>     >
>     >      brc = SetEvent (sync);
>     >      brc = CloseHandle (sync);
>     >
>     >
>     > win_assert and zmq_asserts abort the program if the conditions
>     passed to
>     > them aren't met. If the program is aborted before calling
>     'SetEvent' on
>     > sync, the event is unsetted forever and all zeromq applications that
>     > call this code will block on 'WaitForSingleObject'. A preferred
>     way to
>     > handle this is using 'Mutex' since if this scenario happens,
>     > WaitForSingleObject will not freeze forever but will return
>     WAIT_ABANDONED.
>     > _______________________________________________
>     > zeromq-dev mailing list
>     > zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>     > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>     --
>     -
>     Pieter Hintjens
>     CEO of iMatix.com
>     Founder of ZeroMQ community
>     blog: http://hintjens.com
>     _______________________________________________
>     zeromq-dev mailing list
>     zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>     http://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/20131111/3b1186ec/attachment.htm>