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 >>> >>> > >
