I've got some threads returned by core.async/thread involved in some process, which I'm about to shut down. I'm not shutting down my entire program, just these threads. How can I terminate the threads?
The .stop method of the Java Thread class is deprecated but I'd be happy to use it, except that core.async/thread returns not a Thread, but a ManyToManyChannel:
user=> (clojure.core.async/thread)
#object[clojure.core.async.impl.channels.ManyToManyChannel 0x780e97c0
"clojure.core.async.impl.channels.ManyToManyChannel#780e97c0"]
user=> (type *1)
clojure.core.async.impl.channels.ManyToManyChannel
I haven't found any documentation on ManyToManyChannel. That sounds like a strange name for the type of a thread, so there might be something elementary here that I don't understand. But here's my current naïve, nonsensical-sounding question: How do you kill a ManyToManyChannel?
clojure.repl/thread-stopper seems to have no effect on ManyToManyChannels.
You let the thread terminate naturally. If external termination is necessary, you have to implement it.
(defn terminatable [input-ch terminate-ch]
(thread
(loop []
(let [[v ch] (alts!! [input-ch terminate-ch])]
(if (identical? ch input-ch)
(if (some? v)
(do (process-input v) (recur))
;; else input-ch has closed -> don't call recur,
;; thread terminates
)
;; else we received sth. from terminate-ch,
;; or terminate-ch has closed -> don't call recur,
;; thread terminates
)))))
Then terminate externally via
(close! terminate-ch)
Finally you can determine when the thread is terminated by taking from the channel returned by thread.
I. e.
(take! (terminatable (chan) (doto (chan) close!))
(fn [_] (println "Thread is terminated")))
Related
The basic discussion of queues in the lparallel library at https://z0ltan.wordpress.com/2016/09/09/basic-concurrency-and-parallelism-in-common-lisp-part-4a-parallelism-using-lparallel-fundamentals/#channels says that queues "enable message passing between worker threads." The test below uses a shared queue to coordinate a main and a subordinate thread, where the main simply waits for the completion of the subordinate before exiting:
(defun foo (q)
(sleep 1)
(lparallel.queue:pop-queue q)) ;q is now empty
(defun test ()
(setf lparallel:*kernel* (lparallel:make-kernel 1))
(let ((c (lparallel:make-channel))
(q (lparallel.queue:make-queue)))
(lparallel.queue:push-queue 0 q)
(lparallel:submit-task c #'foo q)
(loop do (sleep .2)
(print (lparallel.queue:peek-queue q))
when (lparallel.queue:queue-empty-p q)
do (return)))
(lparallel:end-kernel :wait t))
This works as expected producing output:
* (test)
0
0
0
0
NIL
(#<SB-THREAD:THREAD "lparallel" FINISHED values: NIL {10068F2B03}>)
My question is about whether I'm using the queue functionality of lparallel correctly or fully. It would seem that a queue is simply a substitute for using a global variable to hold a thread-shared object. What is the design advantage of using a queue? Is it generally good practice to assign one queue to each submitted task (assuming the task needs to communicate)? Thanks for any deeper insights.
Multithreaded work is done by managing concurrent access to mutable
shared states, i.e. you have a lock around a common data-structure,
and each thread read or write into it.
It is however recommended to minimize the number of data being
accessed concurrently. Queues are a way to decouple workers from each
others, by having each thread manage its local state and exchange data
only through messages; this is thread-safe because the access to
queues is controlled by locks and condition
variables.
What you are doing in your main thread is polling for when the queue
is empty; this might work but this is counter-productive, since queues
are used as a synchronization mechanism but here you are doing the
synchronization yourself.
(ql:quickload :lparallel)
(defpackage :so (:use :cl
:lparallel
:lparallel.queue
:lparallel.kernel-util))
(in-package :so)
Let's change foo so that it gets two queues, one for incoming
requests, and one for replies. Here, we perform a simple transform to
the data being sent and for each input message, there is exactly one
output message, but this needs not always be the case.
(defun foo (in out)
(push-queue (1+ (pop-queue in)) out))
Change test so that the control-flow is only based on reading/writing to queues:
(defun test ()
(with-temp-kernel (1)
(let ((c (make-channel))
(foo-in (make-queue))
(foo-out (make-queue)))
(submit-task c #'foo foo-in foo-out)
;; submit data to task (could be blocking)
(push-queue 0 foo-in)
;; wait for message from task (could be blocking too)
(pop-queue foo-out))))
But how can you can avoid polling in test if there are multiple tasks running? Don’t you need to continuously check when any one of them is done so you can push-queue more work to it?
You could use a different concurrency mechanism, similar to listen and poll/epoll, where you watch for multiple
source of events and react whenever one of them is ready. There are languages like Go (select) and Erlang (receive) where
this is quite natural to express. On the Lisp side, the Calispel library provide a similar alternation mechanism (pri-alt and fair-alt). For example, the following it taken from Calispel's test code:
(pri-alt ((? control msg)
(ecase msg
(:clean-up (setf cleanup? t))
(:high-speed (setf slow? nil))
(:low-speed (setf slow? t))))
((? channel msg)
(declare (type fixnum msg))
(vector-push-extend msg out))
((otherwise :timeout (if cleanup? 0 nil))
(! reader-results out)
(! thread-expiration (bt:current-thread))
(return)))
In the case of lparallel, there is no such mechanism, but you can go pretty far with queues only, provided you tag your messages with identifiers.
If you need to react as soon as either a task t1 or t2 gives a result, then make both of those task write in the same result channel:
(let ((t1 (foo :id 1 :in i1 :out res))
(t2 (bar :id 2 :in i2 :out res)))
(destructuring-bind (id message) (pop-queue res)
(case id
(1 ...)
(2 ...))))
If you need to synchronize code for when both t1 and t2 emit result, let them write in different channels:
(let ((t1 (foo :id 1 :in i1 :out o1))
(t2 (bar :id 2 :in i2 :out o2)))
(list (pop-queue o1)
(pop-queue o2)))
Suppose that channel chan has the values "1" and "2" on queue.
Goal: Make a function which takes chan and returns the vector [1 2]. Note that I am totally fine if this function has to block for some time before its value is returned.
Attempt:
(defn chan->vector
[chan]
(let [a (atom true) v []]
(while (not-nil? #a)
(go
(reset! a (<! chan))
(into v #a)
(reset! a (<! chan))
)
) v
)
)
Result: My REPL freezes and eventually spits out a huge error. I have come to realize that this is because the (go ...) block is asynchronous, and so immediately returns. Thus the atom іn my (while ...) loop is never given a chance to be set to nil and the loop can never terminate.
So how do I accomplish the desired result? In case it's relevant, I'm using ClojureScript and targetting nodejs.
you should use alts! from core.async to fulfill this task
(https://clojure.github.io/core.async/#clojure.core.async/alts!):
(def x (chan 10))
(go (>! x 1)
(>! x 2)
(>! x 3))
(defn read-all [from-chan]
(<!! (go-loop [res []]
(let [[v _] (alts! [from-chan] :default :complete)]
(if (= v :complete)
res
(recur (conj res v)))))))
(read-all x)
;; output: [1 2 3]
(read-all x)
;; output: []
(go (>! x 10)
(>! x 20)
(>! x 30)
(>! x 40))
(read-all x)
;; output: [10 20 30 40]
inside the go-loop this (a/alts! [from-chan] :default :complete) tries to read any value from channel, and in case there are no value available at once it emits the default value, so you will see you should break the loop and return accumulated values.
update: as the blocking read (<!!) is absent in cljs, you can rewrite it the following way:
(defn read-all [from-chan]
(go-loop [res []]
(let [[v _] (alts! [from-chan] :default :complete)]
(if (= v :complete)
res
(recur (conj res v)))))))
so it will return the channel, and then just read one value from there:
(go (let [res (<! (read-all x))]
(println res)
;; do something else
))
You can use clojure.core.async/reduce:
;; demo setup
(def ch (async/chan 2))
(async/>!! ch :foo)
(async/>!! ch :bar)
;; background thread to print reduction result
(async/thread
(prn (async/<!! (async/reduce conj [] ch))))
;; closing the channel…
(async/close! ch)
;; …terminates the reduction and the result gets printed out:
;; [:foo :bar]
clojure.core.async/reduce returns a channel that will produce a value if and when the original channel closes. Internally it uses a go block and will release control in between taking elements from the original channel.
If you want to produce a value after a certain amount of time passes whether or not the original channel closes, you can either wrap the original channel in a pass-through channel that will close itself after a timeout passes or you can use a custom approach to the reduction step (perhaps the approach suggested by #leetwinski).
Use into
Returns a channel containing the single (collection) result of the
items taken from the channel conjoined to the supplied collection. ch
must close before into produces a result.
Something like this should work (it should print the events from events-chan given events-chan closes when it is done publishing events):
(go
(println (<! (into [] events-chan))))
The source channel needs to end (close), otherwise you can't put all events into a collection.
Edit:
Re-read your question, and it is not very clear what you want to accomplish. Whatever you want to do, chan->vector needs to return a channel so that whoever calls it can wait for the result. In fact, chan->vector is exactly into:
; chan->vector ch:Chan<Event> -> Chan<Vector[Event]>
(defn chan->vector [ch]
(into [] ch))
(go
(let [events (<! (chan->vector events-chan))]
(println events) ; Do whatever with the events vector
))
As I mentioned above, if the events chan never closes, then you have to do more thinking about how to consume the events. There is no magic solution. Do you want to batch the events by time intervals? By number of events? By a combination of those?
In summary, as mentioned above, chan->vector is into.
While possible in Clojure and many other languages, what you want to do is not possible in ClojureScript.
You want a function that blocks while listening to a channel. However, ClojureScript's version of core.async doesn't include the blocking operators. Why? Because ClojureScript doesn't block.
I couldn't find a reliable source to back that last sentence. There seems to be a lot of confusion around this topic on the web. However, I'm pretty sure of what I'm saying because ClojureScript ultimately becomes JavaScript, and that's how JavaScript works.
Indeed, JavaScript never blocks, neither on the browser nor in Node.js. Why? As far as I understand, it uses a single thread, so if it were to block, the user would be unable to do anything in the browser.
So it's impossible to do what you want. This is by design, because it could have disastrous UX effects. ClojureScript channels are like JavaScript events; in the same way you don't want an event listener to block the user interface while waiting for an event to happen, you also shouldn't want a channel to block while waiting for new values.
Instead, try using a callback function that gets called whenever a new value is delivered.
I only found how to kill a thread that I have assigned to a variable:
(setf *foo* (bt:make-thread (lambda () (loop)) :name "Foo2")) --> (bt:destroy-thread *foo*)
How can I kill just any thread that I can see with (bt:all-threads):
(bt:make-thread (lambda () (loop)) :name "Foo") --> ?
You can kill any thread. There is nothing special about it. If you get a list of threads, just get the thread you want to kill and pass it to the function.
The function destroy-thread does not see a variable. Since it is a function, Lisp uses the usual evaluation rules. It gets passed a thread. The thread just happens to be the value of a variable in your example.
It could be the value of a function call:
(defun my-thread ()
*foo*)
(bt:destroy-thread (my-thread))
or even part of a data structure, for example a list:
(defun my-thread ()
(list 1 *foo* 3))
(bt:destroy-thread (second (my-thread)))
A thread is just another object.
If you get a list of threads, then you need to identify the correct thread. For example by looking at the name of the thread.
(bt:destroy-thread (nth index (bt:all-threads)))
It maybe be good the check if thread is alive, (bt:thread-alive-p <thread>) and not the current one, (bt:current-thread <thread>) Before killing it..
Based on core.async walk through example, I created below similar code to handle some CPU intensive jobs using multiple channels with a timeout of 10 seconds. However after the main thread returns, the CPU usage remains around 700% (8 CPUs machine). I have to manually run nrepl-close in emacs to shut down the Java process.
Is there any proper way to kill macro thread produced by (go..) block ? I tried close! each chan, but it doesn't work. I want to make sure CPU usage back to 0 by Java process after main thread returns.
(defn [] RETURNED-STR-FROM-SOME-CPU-INTENSE-JOB (do... (str ...)))
(let [n 1000
cs (repeatedly n chan)]
(doseq [c cs]
(go
(>! c (RETURNED-STR-FROM-SOME-CPU-INTENSE-JOB ))))
(dotimes [i n]
(let [[result source] (alts!! (conj cs (timeout 10000))) ] ;;wait for 10 seconds for each job
(if (list-contains? cs source) ;;if returned chan belongs to cs
(prn "OK JOB FINISHED " result)
(prn "JOB TIMEOUT")
)))
(doseq [i cs]
(close! i)) ;;not useful for "killing" macro thread
(prn "JOBS ARE DONE"))
;;Btw list-contains? function is used to judge whether an element is in a list
;;http://stackoverflow.com/questions/3249334/test-whether-a-list-contains-a-specific-value-in-clojure
(defn list-contains? [coll value]
(let [s (seq coll)]
(if s
(if (= (first s) value) true (recur (rest s) value))
false)))
In REPL there seems to be no clean way yet.
I first tried a very dirty way by using deprecated method Thread.stop
(doseq [i #threadpool ]
(.stop i))
It seemed worked as CPU usage dropped once the main thread returned to REPL, but if I run the program again in REPL, it'd just hang at the go block part!!
Then I googled around and found this blog and it says
One final thing to note: we don't explicitly do any work to shutdown the go routines. Go routines will automatically stop operation when the main function exits. Thus, go routines are like daemon threads in the JVM (well, except for the "thread" part ...)
So I tried again by making my project into a uberjar and run it on a command console, and it turned out that CPU usage would drop immediately when blinking cursor returns to the console!
Based on answer for another related question How to control number of threads in (go...), I've found a better way to properly kill all the threads started by (go...) block:
First alter the executor var and supply a custom thread pool
;; def, not defonce, so that the executor can be re-defined
;; Number of threads are fixed to be 4
(def my-executor
(java.util.concurrent.Executors/newFixedThreadPool
4
(conc/counted-thread-factory "my-async-dispatch-%d" true)))
(alter-var-root #'clojure.core.async.impl.dispatch/executor
(constantly (delay (tp/thread-pool-executor my-executor))))
Then call .shutdownNow and .awaitTermination method at the end of (go...) block
(.shutdownNow my-executor)
(while (not (.awaitTermination my-executor 10 java.util.concurrent.TimeUnit/SECONDS ) )
(prn "...waiting 10 secs for executor pool to finish") )
[UPDATE]
The shutdown executor method above seems not pure enough. The final solution for my case is to send a function with control of its own timeout into go block, using thunk-timeout function. Credits go to this post. Example below
(defn toSendToGo [args timeoutUnits]
(let [result (atom nil)
timeout? (atom false)]
(try
( thunk-timeout
(fn [] (reset! result (myFunction args))) timeoutUnits)
(catch java.util.concurrent.TimeoutException e (do (prn "!Time out after " timeoutUnits " seconds!!") (reset! timeout? true)) ))
(if #timeout? (do sth))
#result))
(let [c ( chan)]
(go (>! c (toSendToGo args timeoutUnits))))
(shutdown-agents)
Implementation-specific, JVM: both agents and channels use a global thread pool, and the termination function for agents iterates and closes all open threads in the VM. Empty the channels first: this action is immediate and non-reversible (especially if you are in a REPL).
I'm finding it extremely frustrating working out how to kill a thread in Racket.
It seems like it's basic enough that it's not explicitly in any guide or documentation (there's stuff which seems related, but I can't understand how to apply it to my situation because it doesn't offer a mental model for how the process works).
Every time I attempt to (kill-thread thread-name), it returns the error that the thread is in fact a procedure. However, starting the same thread works fine.
What am I doing wrong?
Here's my (horrible) code at the current time, I've never worked much with threads before in or out of Racket so this is probably beyond disgusting:
(define game
(lambda ()
(let loop ()
(sleep 2)
(printf "game running \n")
(loop))))
(define start (lambda () (thread game)))
(define stop (lambda () (with-handlers
([exn:fail?
(lambda (exn)
(displayln (string-append "Failed to kill main game thread. " (exn-message exn)))
#f)])
(kill-thread (start)))))
E: I've tried replacing "(start)" with "game", and thunking/unthinking start/stop in various combinations.
Right now, you're creating the new thread and deleting it immediately with (kill-thread (start)), while the old one is untouched.
If you only need to keep track of the single main game thread (aka thats the only thing passing through start and stop) you can use set! and a global variable to keep track of the thread:
#lang racket
(define game
(lambda ()
(let loop ()
(sleep 2)
(printf "game running \n")
(loop))))
(define GAME-THREAD (void))
(define start (lambda () (set! GAME-THREAD (thread game))))
(define stop (lambda () (with-handlers
([exn:fail?
(lambda (exn)
(displayln (string-append "Failed to kill main game thread. " (exn-message exn)))
#f)])
(kill-thread GAME-THREAD))))