[PATCH] AnyEvent::Handle

Marc Lehmann schmorp at schmorp.de
Thu Jul 5 23:14:06 CEST 2012


On Thu, Jul 05, 2012 at 04:28:44PM +0200, Maxime Soulé <btik-cpan at scoubidou.com> wrote:
> Le 04.07.2012 21:38, Marc Lehmann wrote:
> >On Wed, Jul 04, 2012 at 10:40:25AM +0200, Maxime Soulé<btik-cpan at scoubidou.com>  wrote:
> >>To get round that, I need to put an eval {} in my callback with a
> >>"catch" block that call AnyEvent::postpone to "die" later, just in
> >>case...
> >
> >That is correct.
> 
> OK. So related to what you say below, I must not use "die" in the
> AnyEvent::postpone callback, right? Or is it OK in this case?

You can, but if you let the exception escape to the caller you run into
undefined behaviour, including random memory corruption.

> >The behaviour is the same, and simple, as I have explained. If you think
> >the behaviour is not the same, then can you explain what the difference
> >is?
> 
> "storable" is the only type reader that enclose the callback in an
> eval {}. Even if that does not change what you say later about the
> recv call context.

Yes, but many things enclose stuff into an eval, and in this case, it
doesn't change behaviour.

> Yes sorry, I didn't say previously that I rely on the perl event loop
> that does not seem to catch exceptions. So it seems to me that my
> global eval {} works in this case.

No, because callbacks are not always called directly via the event loop.
For example, if any other module loads Coro, the thread that calls recv
almost never is the thread that calls callbacks. Another example is
AE_DEBUG_WRAP, which again changes behaviour. Behaviour varies widely
depending on a lot of code you don't control.

So, no, a bug is a bug, and undefined behaviour is undefined behaviour. Your
gloable val might work in some cases, but it doesn't work in general, not
even with AnyEvent::Loop.

Or in other words, no matter how amyn hacks you pile on top of each other,
the code stays buggy.

> When I use AnyEvent over EV, I use $EV::DIED to signal (send) the
> global condvar with the error, and so leave the application. Is this
> behaviour correct?

You can call send from EV::DIED, if you mean that. If you mean that this
makes the undefined behaviour defined, then, no, it's not correct (but you
already know that it doesn't work).

> It allows me to consider untrapped exceptions as fatal ones and then
> to quit in these cases.

$EV::DIED doesn't do anything to untrapped exceptions. To catch untrapped
exceptions, you need a fairly elaborate $SIG{__DIE__} handler (for
example, one that walks the callstack to see if it is inside an eval).

> >Which resulted in finding all kinds of bugs in your code, so that's gerat,
> >isn't it? Without it, you'd never find out about the bugs until they are
> >biting you.
> 
> It is... And I am very lucky guy since my eval {} trick did not fool
> me for 4 years :)

Did you really make the effort of actively testing codepaths of whether they
work? If not, then this false sense of security is indeed just a false sense
of security, because most likely, you were just lucky enough because "fatal"
exceptions are rare, and if caught, might even have gone completely
undetected.

So, are you really sure it "did not fool you"? Or do you just not know? :)

-- 
                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