A queue that uses core.async to enable support for delayed events and also provides a run-event-loop!
mechanism
for automatically processing events as they arrive (optional). You may, of course, send the queue the
evts/cancel-event
to exit your machine (without reaching the final state) to cause the run-event-loop!
to
exit.
This queue can support any number of running statecharts via their session-ids. send!
will reject any request that
is missing a target that defines the target session-id. Just use the same instance as the event queue for every
chart.
A queue that uses core.async to enable support for delayed events and also provides a `run-event-loop!` mechanism for automatically processing events as they arrive (optional). You may, of course, send the queue the `evts/cancel-event` to exit your machine (without reaching the final state) to cause the `run-event-loop!` to exit. This queue can support any number of running statecharts via their session-ids. `send!` will reject any request that is missing a target that defines the target session-id. Just use the same instance as the event queue for every chart.
An event queue that does NOT process event delays via any kind of notification system. Delayed events will be queued, and will be kept invisible until you ask for an event AFTER the timout of the event has occured. This means you must manually poll this queue.
This queue DOES support any number of sessions, and maintains separate tracking for each.
This queue DOES NOT support communication with any other kind of system. Only other statecharts with session ids.
There is a helper (next-event-time session-id q)
that will tell you when the next delayed event will be visible
(as an inst) for a given session id.
This allows you to implement your delivery mechanism in concert with your overall system.
The process-next-event!
of this implementation processes all available events in a loop and then returns.
An event queue that does NOT process event delays via any kind of notification system. Delayed events will be queued, and will be kept invisible until you ask for an event AFTER the timout of the event has occured. This means you must manually poll this queue. This queue DOES support any number of sessions, and maintains separate tracking for each. This queue DOES NOT support communication with any other kind of system. Only other statecharts with session ids. There is a helper `(next-event-time session-id q)` that will tell you when the next delayed event will be visible (as an inst) for a given session id. This allows you to implement your delivery mechanism in concert with your overall system. The `process-next-event!` of this implementation processes all available events in a loop and then returns.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close