END block ignored while run_cmd() is executing

Marc Lehmann schmorp at schmorp.de
Thu Apr 12 17:03:07 CEST 2012


On Thu, Apr 12, 2012 at 10:48:09AM -0400, Fulko Hew <fulko.hew at gmail.com> wrote:
> > Otherwise, I need a program that I can use to reproduce the problem, or
> > somebody ahs to analyze the problem on a system where it doesn't work.
> 
> Booting and running off of that 'Fedora 16 Live' DVD
> was a simple test environment.

Ahh, but you no longer sent ^C to the program. I guess the only method to do
that is either use kill from another shell, or strace -p <pid>, to attach
strace from another shell.

> > Do you still get the behaviour if you don't use a blocking wait in
> > obtainer?
> 
> I prefer to have the block in the obtainer so that nothing proceeds till
> the run_cmd() has completed and all the data is available (lest the
> daisy chaining of callbacks become too overwhelming).

Well, it's not supported, and can (and usually will) cause any number of
problems.

Now, if Coro is already there, you cna use an async {} to put this into
it's own coroutine.

> And the END block(s) are now being reached again.  :-)

That sounds like some old versions of Coro and/or AnyEvent - whats the
Coro and AnyEvent versions on Fedora? If debian is ~3 years behind
releases, maybe fedora isn't much newer.

> [It _is_ interesting though, that it doesn't fail in your environments! ]

Actually, now that I read the Coro changelog, only the CVS version
emulates perl exit more closely. Older versions just exit when you exit
from the non-main thread.

It's not easily possible to let perl exit itself, impossible with the
documented api actually, so while END blocks will run, exiting from a
thread will never work.

This is not really a problem for your case, as this is caused by illegally
blocking in the event callback, which (with current versions of Coro) runs
another event loop in another thread.

> In retrospect, I see and understand the 'block in an event loop'
> issue. Unfortunately its a very common paradigm to (accidentally)
> fall into.  Ie. Every once in a while 'do something (non-trivial that
> involves events)'.

Yes, that's why AnyEvent errors in some cases where it can detect it.
However, neither Coro nor AnyEvent control the event loop, so can't check
all the time.

It's also a good reason to never write blocking interfaces, because if you
have a continuation callback you can always use async{} for "blocking" stuff
(which menas conveniently waiting for some dsata while the rest of the
program does continue to run).

It's only a problem when you have to return things from a callback, which
is a sign for a non-event-based interface actually.

> Your warning is heeded, but in my case (not the 'F16 Live' test case)
> my system didn't even have Coro available, so I had installed the latest
> and greatest from CPAN.

It all makes sense now.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the anyevent mailing list