[kepler-users] Asynchronous source Model of Computation
Timothy McPhillips
tmcphillips at mac.com
Fri Aug 7 11:06:58 PDT 2009
Hi Chris,
How does your workflow knows when to stop? One advantage of using the
prefire/fire/postfire pattern in designing an actor is that it
provides the actor a way of telling the workflow system that it isn't
going to do any more work or produce more tokens. I tend to write PN
workflows that depend on the first actor in the workflow declaring
when it has produced all the tokens that is going to produce (by
returning false from postfire); the system can then see to it that
downstream actors wrap up nicely and don't wait forever for data which
is never going to arrive.
Perhaps in your actors, the fire and postfire methods could interact
with the other thread such that, say, the fire method returns each
time a token is emitted, and postfire returns false when there are no
more tokens to output? Or does that make no sense in your case?
Cheers,
Tim
On Aug 7, 2009, at 8:17 AM, Chris Weed wrote:
> I have several actors that are token sources that generate tokens
> asynchronously.
> An example is an actor that connects to a UDP port and produces
> tokens from
> packets it receives.
> The actors essentially initialize a separate thread, which
> asynchronously outputs tokens
> to an output port. My prefire, fire, and postfire functions are empty,
> and when used
> with the PN director seem to bog down the system. It looks like
> these empty
> functions just get called over and over. To overcome this, I put a
> non-ending while-loop
> in the fire method to just sleep the actors main thread. I am curious
> if this is the correct
> way to do this, or am I missing something.
> Chris
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
More information about the Kepler-users
mailing list