This patch breaks out the signal handling such that the core.async abstraction surrounding signals is now optional. There is a new function:
temporal.signals/register-signal-handler!
that offers low-level access to the signal callback. The design was inspired by the work of Thomas Moerman (https://github.com/tmoerman) in the Query support
This work prompted another cleanup that I had been meaning to do: the removal of the 'ctx' from the defworkflow. The original design had both defworkflow and defactivity receiving a user supplied 'ctx', but this never made sense for workflows since the context invites non-determinism.
So, the new signature of defworkflow is simply a single-arity function that receives the arguments directly, rather than within a {:keys [signals args]} map. We still support 2-arity clients (for now) with a backwards compatibility check within the macro. This may be removed in a future release, so we print a WARN to signal the developer of the deprecation.
This patch breaks out the signal handling such that the core.async abstraction surrounding signals is now optional. There is a new function:
that offers low-level access to the signal callback. The design was inspired by the work of Thomas Moerman (https://github.com/tmoerman) in the Query support
(See https://github.com/manetu/temporal-clojure-sdk/commit/4f052aeecd5d36cac0d1c2e1e95b72b23e5b2be7)
This work prompted another cleanup that I had been meaning to do: the removal of the 'ctx' from the defworkflow. The original design had both defworkflow and defactivity receiving a user supplied 'ctx', but this never made sense for workflows since the context invites non-determinism.
So, the new signature of defworkflow is simply a single-arity function that receives the arguments directly, rather than within a {:keys [signals args]} map. We still support 2-arity clients (for now) with a backwards compatibility check within the macro. This may be removed in a future release, so we print a WARN to signal the developer of the deprecation.