Windows 8, ZeroMQ 3.2.2. I think that the problem is that the
application is running in a test environment that doesn't close it
graceously, instead it just terminates the application which leaves the
possibility for that event to hang around. I have not tested with libzmq
master, I have just fixed it myself using the mutex and the problem has
gone away.
Sure, I can submit the change mutex + port change myself.
Em 13/11/2013 11:11, KIU Shueng Chuan escreveu:
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"
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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 list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
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
