Here's one idea, basically put "channel on a channel" idea:
(defonce main-c (chan 1))
(defn start-main-channel-loop []
;put channels on the channel in the order that they need to execute
(go
(loop []
(let [c (<! main-c) ;wait for channel
from the main channel
x (<! c)] ;wait for 'x' from
channel 'c'
;do stuff with x, it can dispatch based on the data that is 'x'
(println "x ::: " x)
(recur)))))
(comment
(let [i-run-before-callback-c (chan 1)
callback-c (chan 1)]
;"schedule" things to run in desired order
(put! main-c i-run-before-callback-c)
(put! main-c callback-c)
;run in go to ensure order of events
(go
;>! this first
(>! callback-c [:second {}])
;wait 3 seconds for demo purposes
(<! (timeout 3000))
;>! this second
(>! i-run-before-callback-c [:first {}]))))
After about 3 seconds you should see this printed:
*x ::: [:first {}]*
*x ::: [:second {}]*
... i.e. even though we scheduled *[:second {}]* before *[:first {}]*, they
appear in the desired order at the end.
On Friday, May 3, 2019 at 1:47:10 AM UTC-7, Tom Locke wrote:
>
> In the early core.async presentation, Rich argues that we should avoid
> putting application logic in callback handlers, and instead build the
> "machine like" parts of our code in the core.async model. To bridge from
> callback world to core.async we have put! and take! which we should call as
> soon as possible.
>
> But what do we do if the library we are interfacing with relies on some
> effect having happened *before* the callback returns, but our application
> architecture dictates that effect should come from some other process? (go)
> (put!) and (take!) all return immediately.
>
> According to my (hopefully incorrect!) understanding, it's not possible.
>
> It seems to me we need something like (<!!), which is not available in
> cljs due to the lack of real threads.
>
> However, could we not have an implementation of (<!!) that goes something
> like this?:
>
> (defn <!! [c]
> (loop
> (or (poll! c)
> (if (any-process-ready?)
> (do
> (schedule-next-process!)
> (recur))
> (throw "deadlock!")))))
>
> This is making some uninformed assumptions about the scheduler, but
> presumably there must be:
>
> - Some kind of list of ready (not blocked on channel operations)
> processes
> - The ability to run a ready process until the next scheduling point (or
> until it runs out of processes).
>
> However I believe the scheduler is to be considered private/opaque, so a
> proper "userland" implementation would not be possible.
>
>
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
