[kepler-users] Asynchronous source Model of Computation
Timothy McPhillips
tmcphillips at mac.com
Fri Aug 7 11:26:32 PDT 2009
Hi Chris,
Ok, then your workflow is meant to stop when you hit the "Stop"
button. I'm curious to know if that works with your actor written the
way it is?
Tim
On Aug 7, 2009, at 11:19 AM, Chris Weed wrote:
> 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