[kepler-users] receiving tokens on different ports

[Chris Weed]

Yea, the idea of using multiple inputs is that the display is going to
be a GIS display
with different data layers. Each channel connected to the display will
be a different
layer in the display. So one layer could be a series of detections on
top of another
layer with some aerial imagery, etc. These input data sources will
feed data at different
times, but the idea is that it would update that layer as the data comes in.
I will look into the extended PN model to see if that fits, or maybe
try the threading.
I'm sorry I wasn't a little more specific about what the display shows,
and the use case.
Chris

On Fri, Aug 14, 2009 at 1:20 PM, Edward A. Lee<eal at eecs.berkeley.edu> wrote:
>
> PN has "blocking read" semantics. Here is a paper on why this is:
>
> http://ptolemy.eecs.berkeley.edu/publications/papers/95/processNets/
>
> A consequence is that in PN, there is no such thing as a port
> that has no input token available.
>
> There are two ways to accomplish what you want:
>
> 1) Build an actor in extended PN that is nondeterminate.
>   The NondeterminateMerge actor can serve as a model.
>
> 2) Use multiple actors. This seems like the right solution.
>   Why do you want this in one actor?  Anything the actors
>   post to the GUI has to be done in the event thread anyway,
>   so there is no real advantage to having them in separate
>   threads...
>
> Edward
>
>
> Chris Weed wrote:
>>
>> I am creating a custom display that receives different data types on
>> different ports,
>> image URL on one, GML data on another, etc.
>> When my actor fires, any one of these ports could have new data.
>> How do I figure out which one when I am using the PN director?
>> Normally, I would just loop through all of the ports, but
>> won't the port always return true for hasToken and then block when I call
>> port.get()?
>> I am confused how this should work.
>> Chris
>> _______________________________________________
>> Kepler-users mailing list
>> Kepler-users at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>