borodust/cl-flow

Reactive computation tree library for non-blocking concurrent Common Lisp

CL-FLOW

Library for asynchonous non-blocking concurrency in Common Lisp.

Documentation

Documentation at borodust.org

You can hear my lengthy-bad-english explanation of cl-flow operation in Common Lisp Study Group: Concurrency in Common Lisp Part 2 video from Atlanta Functional Programming group.

Tests

(ql:quickload :cl-flow/tests)
(5am:run! :cl-flow-suite)

cl-flow's Issues

CAS-cycle for parallel dispatch safety

As of now, parallel dispatch (~>) is guarded by a bt's lock, which is not ideal.
See lock usage in dispatch-parallel-flow function.

Nickname clash with http://quickdocs.org/flow/

cl-flow's nickname flow clashes with flow's package name.

Uses cl-muth:make-atomic-counter which doesn't exist

cl-muth does not seem to have make-atomic-counter.

Some systems failed to build for Quicklisp dist

Building with SBCL 2.1.10 / ASDF 3.3.5 for quicklisp dist creation.

Trying to build commit id bb95fda

cl-flow fails to build with the following error:

; caught WARNING:
;   * is not permitted as an argument to the FUNCTION type specifier
; 
; caught WARNING:
;   * is not permitted as an argument to the FUNCTION type specifier
...
Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1001C08103}>: COMPILE-FILE-ERROR while compiling #<CL-SOURCE-FILE "cl-flow" "context">

cl-flow/tests fails to build because of a failure in cl-flow.

Full log here

Implement condition to wrap errors in atomic blocks

Instead of *> operator

Implement *> operator

*> operator will intercept conditions unhandled in the -> blocks.

Usage gonna be somewhat like this:

(>> (-> :tag ()
      (error "must be raised here"))
    (-> :tag ()
      (normal-op))
    (*> :tag (e)
      ;; process condition raised in the first form skipping second form
      ;; return value that next form must be able to consume or rethrow?
      (process-condition e))
    (-> :tag (arg)
      (consume-result-of-normal-op arg)))

Incorrect flow elements

If, for example, function used in a place where a flow element must be, but doesn't represent a correct flow callback, unobviuos things happen. Condition raised in runtime won't provide much useful information to find a culpirt in this case.

(>> (function-returning-flow)                   ; ok
    (function-returning-neither-flow-nor-list)) ; hard-to-locate error

That's a programming error, but hard to catch atm. Some checks need to be added.

Aliases for operators

Put your suggestions here.

Winning variants:
-> - flow:atomically
~> - flow:concurrently
>> - flow:serially
->> - flow:dynamically

Destructure block arguments

If result is received from ~> operator, it uses ((fn-0-values) (fn-1-values) ... ) format, which can be bound to next block by (-> :tag (v0 v1 ... ) ... ) where v0 and v1 gonna be lists. We probably should allow simple destructuring to simplify user's burden, e.g.:

(>> (~> (-> :a () 1)
        (-> :b () 2)
        (-> :c () 3))
    (-> :tag ((a) (b) (c))
      (= 6 (+ a b c))))

Better documentation

Including docstrings