[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