Pardon my misreading...

Michael Alan Dorman mdorman at ironicdesign.com
Tue Jan 1 16:36:46 CET 2013


Darin, Marc, I appreciate your responses.

I fear I did a poor job of explaining my concern---using 'synchronous'
in my description and 'sleep' in my example obscured my intent.

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.

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.

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---and I fear it could lead to unexpected latency in end-user
code if a library writer makes use of it.

Mike.



More information about the anyevent mailing list