Harbors with two or more input docks

Added by Girish Subramanian, last edited by Girish Subramanian on Oct 25, 2007  (view change)

There was a small confusion in the class reagrding , what happens when a Harbor has more than one input docks.

Here is what I observed,

#When a harbor has more than one input dock, Fluency waits till the "Ships" dont arrive at all the docks. In other words, Fluency fires the harbor only when all the ships arrive at their respective docks.There may be a case that no ships arrive at dock 1 and 2 ships have already reached dock 2. Harbor is fired as soon as a Ship reaches dock 1.

#Fluency maintains a queue near the docks. So in the above case if 3 ships arrive at dock 2, then the ships at dock 2 are served at first come first serve basis.

#We can also say that the ships are cached and there may be cases when a recent version of ship from dock 1 and a older version of ship from dock 2 , are passed as an input to the harbor.

All these work are done by the Harbor class.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (1)

 

  1. Oct 26, 2007

    whoknows says:

    i'd thought that that's more or less the conclusion we came to in the last class...

    i'd thought that that's more or less the conclusion we came to in the last class after you reported on what you'd found in the harbor class. i think it's a reasonable first cut at supporting actions in fluency.

    other questions came up though:

    1. are harbors observers of the engine's clock? (michelle said that they were in a practical sense, but not the usual direct sense where there's an explicit Observer interface etc). i'd like that clarified.
      1. what about harbors inside molecule widgets? (assuming that molecules really are supported in the current codebase, that is)
      2. are harbors with no inputdocks also ticked by the clock? (ex: if you make a simple timer widget in fluency without its own thread will it still work?) (note: i know that we already have a real time widget in fluency).
    2. the clock discretizes time, so that everything happens in specific timesteps, so if a widget's harbor needs 2 inputs, it could happen that one gets filled, then the other gets filled, then the trigger actually happens (correct me if i'm wrong anywhere!), which means that it could take 3 timesteps before the action actually happens depending on how 'fast' the widget outputdocks that the harbors inputdocks are connected to are producing data. are there cases in fluency now where that leads to undesirable consequences? (i.e. where the author's model of what will happen isn't what fluency actually then does?) if not, it seems to me we don't need to worry about it just now.

    gjer