Arc Forumnew | comments | leaders | submitlogin
2 points by akkartik 4695 days ago | link | parent

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 4695 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 4695 days ago | link

Yeah, seems reasonable.

-----