Pardon my misreading...

[Marc Lehmann]

On Wed, Jan 02, 2013 at 09:39:28AM -0500, Michael Alan Dorman <mdorman at ironicdesign.com> wrote:
> 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?

Don't make it a standard of accuracy - you simply haven't explained
yourself very much, even though I asked you to explain what your goals are
etc. At the moment, it looks as if you insist on implementing something in
a specific (and likely wrong) way. While we can talk about this wrong way,
most likely, it's, well, wrong.

To actually be able to help you with your *actual* problem, you need to
explain what your goal is, not how _you_ think you _need_ to implement
that goal.

In any case, that description isn't true of postpone - the documentation
is what counts in this case, and any extra behaviour you see is spurious -
if you rely on it, you have a bug.

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

Event loops don't "fire". While I can imagine a lot of definitions of
what "fire" means, I can't come up with a definition that would make your
statement true.

You seem to be under the assumption that AE::timer is somehow magic,
but it isn't. The behaviour of postpone is not different between using
one timer per callback and one timer for all callbacks: If you see any
difference, that is up to undocumented implementationd etails that change
between versions and event loops.

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

Which is true for the current implementation of postpone, but not reliable
behaviour.

> 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

The event loop, in all practicality, always runs. If you mean that the
event loop needs to delay invoking the callback until the next-next
iteration or somesuch, then you are wrong.

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

You don't have to apologise for being unclear. But your apparent refusal to
answer questions makes it hard to help you. So if you don't want to explain
what you are tryign to achieve it is a bit frustrating indeed.

I can only urge you not to implement anything based on false assumptions
on how timers work, though - people have tried in the past to divine some
magic behaviour out of 0-time-timers, and have consistently failed.

Again, since you are not telling what you are aiming for, I can't know if
you are about to fail too, but it does seem likely from your descriptions.

Maybe you are looking for idle watchers?

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