[kepler-users] Asynchronous source Model of Computation

[Chris Weed]

Actually, I just realized I don't need to have the fire function wait forever.
It just needs to wait a sufficiently long period of time to not cycle through
the prefire/fire/postfire too often.
I changed the actor to have its thread sleep for 1 second during each
fire call, and
when I hit stop it did call my wrapup function.
Chris

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