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
