[kepler-users] Asynchronous source Model of Computation

Chris Weed chrisweed at gmail.com
Fri Aug 7 11:19:56 PDT 2009


Hi Tim,

The data is just streaming in from a port, and there really is no end.
My workflow is really creating a long running system that will receive
tokens forever as long as the server on the UDP port is working.

I suspect my use case is very different from what you describe where
you process a fixed set of data. In my case, the data is streaming in from
a real-time sensor that is always running. By connecting to the
server port, I can analyze the data. I generally end the workflow
by hitting the "stop" button since the data doesn't end.
This should call the wrapup function of my actor to close the port,
I presume, but I have never tested that.

Chris

On Fri, Aug 7, 2009 at 2:06 PM, Timothy McPhillips<tmcphillips at mac.com> wrote:
> 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