Liking cljdoc? Tell your friends :D

com.fulcrologic.statecharts.event-queue.core-async-event-loop

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.
raw docstring

com.fulcrologic.statecharts.event-queue.manually-polled-queue

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.
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close