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 <[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> 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
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
