Arc Forumnew | comments | leaders | submitlogin
(bug?) kill-thread can't kill atomic-invoked threads?
4 points by dido 4724 days ago | 3 comments

    arc> (= val nil)
    nil
    arc> (def test (x) (atomic-invoke (fn () (sleep 300) (= val x))))
    #<procedure: test>
    arc> (= thr (thread (test 1)))
    #<thread: thr>
sometime before the five-minute wait in test finishes

    arc> (kill-thread thr)
about five minutes later...

    #<void>
    arc> val
    1
It seems that kill-thread didn't actually kill anything. If it did, then val should still be nil. Instead, it seems that kill-thread actually made my REPL join the thread instead of killing it! It made my REPL wait for the remainder of the five-minute sleep and then set val to 1. Apparently break-thread does exactly the same thing.

Removing the atomic-invoke in test so it looks like

    (def test (x) (do (sleep 300) (= val x)))
appears to make kill and break do what one might think. I don't think I want to duplicate this sort of behavior in Arcueid...


2 points by akkartik 4724 days ago | link

I think I introduced that to avoid a deadlock: http://arclanguage.org/item?id=11142 (that's when I realized that all atomics share a single mutex.)

-----

4 points by dido 4723 days ago | link

What I have done with Arcueid is to forcibly remove ownership of the atomic lock from any thread that is killed in that way. The code you have linked there has no problems on Arcueid for that reason. I tend to think of kill-thread as like doing a kill -9, and a thread that gets it will terminate immediately, and just as with kill -9 whoever does it gets to clean up the rest of the mess afterwards. All guarantees about atomicity get thrown out the window. If you wanted to preserve atomicity then you should have used break-thread or some other more pansy-sounding function to attempt to terminate it. :) Thus, break-thread would have the use case of running a computation for some time and then aborting it. The use case for kill-thread, I think, should be an attempt to stop some runaway computation immediately. If a thread is blocked inside an atomic you might want to stop it no matter what.

-----

1 point by akkartik 4723 days ago | link

Yeah, seems reasonable.

-----