Dynamic Pipelines in Filament #107
rachitnigam
started this conversation in
Ideas
Replies: 1 comment
-
|
#1 is also relevant |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
(Moved from #10)
I was wondering a couple of related questions:
[G, L]or[G, max(G, L)+1]as opposed to[G, G+n].A trivial multi-event component is one that essentially has different "paths"
running through its signals associated with an individual event:
The signature of this components tells us that the two events,
GandLdo not interact in any observable way; if they did, at least one of the outputs would have a lifetime that depended on both of them.One of the simplest non-trivial multi-event component is a Latch:
The
outsignal of the latch requires that it be available till the eventLoccurs. Thewrite_ensignal enforces that the latch cannot be used again till at least the eventLhas been observed. Because the implementation of theLatchdoes not provide a way to observe theLevent, there is no Filament program that can construct signal available from[G+1, L]; this meansLatchis necessarily implemented as an extern.Another non-trivial multi-event component is the following
Joincomponent which provides its output when both the input tokens,leftandrightarrive:This is a truly dynamic component:
GandLare entirely unrelated and unordered which means either event can fire first. In fact, different invocations can have different orders ofGandLfiring.The
interfaceports for the two events require that the module may not be used tillmax(G, L)has been observed, which again, is a truly dynamic event in the system.Beta Was this translation helpful? Give feedback.
All reactions