bugLiberty Eiffel - Bugs: bug #39188, øMQ programs don't quit on Ctrl-C

 
 

bug #39188: øMQ programs don't quit on Ctrl-C

Submitted by:  Cyril Adrian <cadrian>
Submitted on:  Fri 07 Jun 2013 09:26:12 AM UTC  
 
Category:  Wrappers Severity:  3 - Normal
Priority:  3 - Low Status:  Postponed
Assigned to:  Paolo Redaelli <Tybor> Open/Closed:  Open
Release:  curtiss Fixed Release:  None
Planned Release:  curtiss

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 23 Aug 2018 07:36:56 PM UTC, comment #2:

Better provide the full quote from the manual:

Making a Clean Exit
Classy programmers share the same motto as classy hit men: always clean-up when you finish the job. When you use ØMQ in a language like Python, stuff gets automatically freed for you. But when using C, you have to carefully free objects when you’ re finished with them or else you get memory leaks, unstable applications, and generally bad karma.
Memory leaks are one thing, but ØMQ is quite finicky about how you exit an application. The reasons are technical and painful, but the upshot is that if you leave any sockets open, the zmq_ctx_destroy() function will hang forever. And even if you close all sockets, zmq_ctx_destroy() will by default wait forever if there are pending connects or sends unless you set the LINGER to zero on those sockets before closing them.
The ØMQ objects we need to worry about are messages, sockets, and contexts. Luckily it’ s quite simple, at least in simple programs:
• Use zmq_send() and zmq_recv() when you can, it avoids the need to work with zmq_msg_t objects.
• If you do use zmq_msg_recv(), always release the received message as soon as you’ re done with it, by calling zmq_msg_close().
• If you are opening and closing a lot of sockets, that’ s probably a sign that you need to redesign your application. In some cases socket handles won’ t be freed until you destroy the context.
• When you exit the program, close your sockets and then call zmq_ctx_destroy(). This destroys the context. 


Hans Zwakenberg <hzwakenberg>
Project Administrator
Thu 23 Aug 2018 07:34:39 PM UTC, comment #1:

from the ZMQ manual:

The ØMQ objects we need to worry about are messages, sockets, and contexts. Luckily it’ s quite simple, at least in simple programs:
• Use zmq_send() and zmq_recv() when you can, it avoids the need to work with zmq_msg_t objects.
• If you do use zmq_msg_recv(), always release the received message as soon as you’ re done with it, by calling zmq_msg_close().
• If you are opening and closing a lot of sockets, that’ s probably a sign that you need to redesign your application. In some cases socket handles won’ t be freed until you destroy the context.
• When you exit the program, close your sockets and then call zmq_ctx_destroy(). This destroys the context. 


Summary: clean exits are only possible if not only the socket or the context is closed, but the corresponding queues are empty as well....

Hans Zwakenberg <hzwakenberg>
Project Administrator
Fri 07 Jun 2013 09:26:12 AM UTC, original submission:

Programs using øMQ library does not react properly on a Ctrl-C.

To quit they have to be killed.

I suspect that øMq is replacing the standard handler set by SmartEiffel runtime

Cyril Adrian <cadrian>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hzwakenberg (Posted a comment)
  • -email is unavailable- added by Tybor (Updated the item)
  • -email is unavailable- added by ramack (Updated the item)
  • -email is unavailable- added by cadrian (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-15 Tybor StatusNone => Postponed
        Assigned toNone => Tybor
        ReleaseNone => curtiss
    2015-12-26 ramack Planned ReleaseNone => curtiss
    2013-08-05 cadrian Priority5 - Normal => 3 - Low

    Back to the top


    Powered by Savane 3.3