Pardon my misreading...

Marc Lehmann schmorp at schmorp.de
Wed Jan 2 09:36:28 CET 2013


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.

> Re-reading the documentation, I see a glimmer of recognition of this
> behavior, but I think users would be better served by a straightforward
> statement that the *only* guarantee is that the current function will
> not be in the call-stack by the time your code is executed, and if you
> want to be certain the event loop will fire, you should use the
> "AE::timer 0, 0" idiom.

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.

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.

> Incidentally, as a user, I find this difference in behavior makes it
> useless to me---I will simply use the "AE::timer 0, 0" idiom instead

I suspect that there is no difference in behaviour. If you see any
difference, than that's just chance and luck and/or choice of event
loop,or relying on undocumented effects that can change at any time.

> and I fear it could lead to unexpected latency in end-user
> code if a library writer makes use of it.

I'd say it's just plain wrong, but again, since you didn't answer any of
my questions, thats your problem to keep.

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