Pardon my misreading...

[Marc Lehmann]

On Tue, Jan 01, 2013 at 03:26:53PM -0700, Darin McBride <darin.mcbride at shaw.ca> wrote:
> That is, I don't think it would be normal, and thus not particularly 
> interesting, that you'd call postpone recursively.  Instead, I would expect 
> that whatever is in the postponed part is either going to run quickly, or 
> going to create some more events with callbacks to be called during the event 
> loop.

It would be entirely fine to do recursive postpone calls. It makes nos
ense to do them directly from the postpone callback, but it would arise
naturally if you call any function inside it that in turn relies on
postpone to do it it's job (such as tcp_connect).

> Sorry, I'm missing the distinction.  AE::postpone simply is a deferral to the 
> end of the *current* loop, and if you're in one postpone, you're already at 

I feel you are both making up things about postpone that aren't really there
:)

The documentation even mentions it will *in practise* be executed shortly
before or after the event loop polls for events, which is as close as it
gets.

I think the problem here is that the OP wants to rely on internal
behaviour of the event loop, and that would be a bug in any case: If it
makes a diference whether your callback is called before or after polling
then your program logic is broken.

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