manifold.go-off — manifold 0.4.2

Provides a variant of core.async/go that works with manifold's deferreds and streams. Utilizes core.async's state-machine generator, so core.async must be provided by consumers as a dependency.

<! clj

(<! deferred-or-stream)

Takes value from a deferred/stream. Must be called inside a (go-off ...) block. Will return nil if a stream is closed. Will park if nothing is available. If an error is thrown inside the body, that error will be the return value.

N.B. To make go-off usage idiomatic with the rest of manifold, use <!? instead.

<!? clj macro

(<!? deferred-or-stream)

Takes a value from a deferred/stream. Must be called inside a (go-off ...) block. Will park if nothing is available. If the value returned is a Throwable, it will be re-thrown.

go-off clj macro

(go-off & body)

Asynchronously executes the body on manifold's default executor, returning immediately to the calling thread. Additionally, any visible calls to <!? and <! deferred operations within the body will block (if necessary) by 'parking' the calling thread rather than tying up an OS thread. Upon completion of the operation, the body will be resumed.

Returns a deferred which will receive the result of the body when completed. If the body returns a deferred, the result will be unwrapped until a non-deferrable value is available to be placed onto the return deferred.

This method is intended to be similar to core.async/go, and even utilizes the underlying state machine-related functions from core.async. It's been designed to address the following major points from core.async & vanilla manifold deferreds:

• core.async/go assumes that all of your code is able to be purely async and will never block the handling threads. go-off removes the concept of handling threads, which means blocking is not an issue, but if you spawn too many of these, you can create more threads than the OS can handle.
• core.async/go has no built-in way of handling exceptions and assumes all async code will be either written defensively, or have custom error propagation, which differs from how clojure code blocks typically work outside of the async world.
• deferred/let-flow presumes that every deferrable needs to be resolved. This prevents more complex handling of parallelism or being able to pass deferreds into other functions from within the let-flow block.
• deferred/chain only works with single deferreds, which means having to write code in unnatural ways to handle multiple deferreds.

go-off-with clj macro

(go-off-with executor & body)

An implementation of go-off that allows specifying the executor to run on. See docstring of go-off for usage.