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

[KIU Shueng Chuan]

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> 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> 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
> > 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
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131109/b0a82dfd/attachment.htm>