Okay - that was my suspicion from my own testing, but I was not sure.
For select() then I guess if I uses exclusively alarm instead of yield, I
can then use yield when I'm looking for a "do me first" kind of deal.
Does this order change if one use Event.pm instead of select? Event seems to
support a priority system of sorts, which is what I'm looking for. If I can
penetrate to it from within POE, that would be perfect. My only other option
is to write a state machine to feed events one by one to a new one. I also
worry about enqueuing too many states for it to be able to handle.
- MW
-----Original Message-----
From: Torvald Riegel [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 04, 2001 1:55 PM
To: Wilkinson, Mike; [EMAIL PROTECTED]
Subject: Re: yield, alarm and signal precedence
On Mon, Jun 04, 2001 at 12:37:15PM -0700, Wilkinson, Mike wrote:
> I'm writing some complex state machines which require quite a bit of state
> queuing. My question is using what methodology does POE choose what state
of
> which machine it runs next, if there are various types of event traffic
> involved at the same time? For example, say in a given state I issue a few
that depends on the event loop. check POE/Kernel/* and pick the one you use,
for poe's loop this seems to be select first, then alarms, then normal fifo
events.
> yields, alarms, and signals. Furthermore, there may also be yields,
alarms,
> and signals that where enqueued by previous states, that have not been
> processed yet. In what order (if any) would the POE kernel go about
> processing these requests, past and present? Also, beyond just alarms, is
> there some way of looking at this "queue list" and see in advance to what
> session and state I'm going next (and beyond)?
events should reach sessions in the order they were sent. anything else
would
make no sense. i don't think you should rely on anything else.
and i don't think there is an official interface for working with the event
fifo, you shouldn't do it anyway. try to find a cleaner way or say a bit
more
about what you're trying to do.
the type of state machine that poe sessions implement isn't made for reading
more input (events) than just the first from the fifo. If you have different
related events pack them together or use the heap to keep track of the
state.
torvald
