Re^4: Tk Mainloop

I was trying undef without success. I was hopeful about Object::Destroyer, but that didn't help my problem. It was good to discover though! But I'm about to give up.

The strange thing is that creating a totally unrelated object can cause Mainloop to not exit. Why would Mainloop even care?

Comment on Re^4: Tk Mainloop - no exit.

Replies are listed 'Best First'.
Re^5: Tk Mainloop - no exit. by zentara (Cardinal) on Nov 11, 2010 at 13:00 UTC
Why would Mainloop even care? Well maybe its a situation where MainLoop dosn't know! Something in that asterisk code is probably blocking the MainLoop's eventloop from working. Here is a big clue. From the AMI.pm: Warning - Mixing Event-loops and blocking actions If you are running an event loop and use blocking methods (e.g +. get_response, check_response, action, simple_action, connected) the outcome is unspecified. It may w +ork, it may lock everything up, the action may work but break something else. I have tested it and behavior s +eems unpredictable at best and is very circumstantial. If you are running an event-loop use non-blocking callbacks! I +t is why they are there! However if you do play with blocking methods inside of your lo +ops let me know how it goes. [download] You may need to work out those non-blocking methods. I would say you are best off forking the asterisk code off, or putting it into a thread of it's own. I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply] [d/l]

Replies are listed 'Best First'.

Re^5: Tk Mainloop - no exit.
by zentara (Cardinal) on Nov 11, 2010 at 13:00 UTC

Why would Mainloop even care?

Well maybe its a situation where MainLoop dosn't know! Something in that asterisk code is probably blocking the MainLoop's eventloop from working. Here is a big clue.

From the AMI.pm:

Warning - Mixing Event-loops and blocking actions

        If you are running an event loop and use blocking methods (e.g
+. get_response, check_response, action,
        simple_action, connected) the outcome is unspecified. It may w
+ork, it may lock everything up, the action may
        work but break something else. I have tested it and behavior s
+eems unpredictable at best and is very
        circumstantial.

        If you are running an event-loop use non-blocking callbacks! I
+t is why they are there!

        However if you do play with blocking methods inside of your lo
+ops let me know how it goes.
[download]

You may need to work out those non-blocking methods. I would say you are best off forking the asterisk code off, or putting it into a thread of it's own.

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

[reply]
[d/l]