Pardon my misreading...

[Michael Alan Dorman]

Marc Lehmann <schmorp at schmorp.de> writes:
> On Tue, Jan 01, 2013 at 10:36:46AM -0500, Michael Alan Dorman <mdorman at ironicdesign.com> wrote:
>> I was surprised to find that while a single call to AE::postpone does
>> not block the event loop from running, multiple consecutive calls to
>> AE::postpone will block the event loop from running until they all
>> complete, and recursive calls further contribute to this.
>
> This is not true, for any meaning of blocking that I can come up with.

I apologize for once again using terminology that has some very specific
associations in computer science that do not apply in this instance.

Perhaps "Multiple consecutive calls to AE::postpone will prevent the
event loop from having an opportunity to run until they all complete, as
will recursive calls to postpone." describes things in a way that meets
your standard of accuracy?

Perhaps the code can help me explain:

  our $POSTPONE_W;
  our @POSTPONE;

  sub _postpone_exec {
     undef $POSTPONE_W;

     &{ shift @POSTPONE }
        while @POSTPONE;
  }

  sub postpone(&) {
     push @POSTPONE, shift;

     $POSTPONE_W ||= AE::timer (0, 0, \&_postpone_exec);

     ()
  }

The first call to postpone shoves the coderef in @POSTPONE and does
"AE::timer 0, 0, _postpone_exec", which guarantees that the event loop
will fire before the code is invoked.  But if you call postpone again
before entering the event loop (allowing that timer to fire), or from
within the coderef itself, those calls will be queued into @POSTPONE,
and will all have to run to completion before control can ever return to
the event loop.

> AE::timer 0, 0 does not guarantee any of that, or even diferent behaviour
> than postpone. And why would that be relevant? The documentation of
> postpone is precise, the problem seems to be that you are trying to abuse
> it in a way that it isn't documented for. Adding further documentation for
> that case will just confuse the issue further.

I appreciate your helping me to refine my communication abilities.

What I meant was that in order for the coderef passed to "AE::timer 0,
0" to be called, the event loop must have an opportunity to
run---otherwise the AE::timer will never fire.  Therefore, using
"AE::timer 0, 0" is a way to make sure that the event loop is run before
the coderef in question is executed.

But yes, you are entirely correct that calling "AE::timer 0, 0" does not
guarantee that the event loop will run, only that it will have run
before the code handed to AE::timer is called.

> Without answering my questions though, I cannot help you further. I would
> suggest however than whatever you are trying to achieve will just not
> work the way you expect it to and at best you are relying on undocumented
> behaviour.

I am afraid my consistent inability to express myself well has confused
the issue.  I don't want to waste any more of your time.  Please accept
my apologies for bothering you.

Mike.