freenode/#clasp - IRC Chatlog
Search
3:08:42
drmeister
If a generic function on an object is being evaluated in one thread when that object is changed in another thread - then there is a catastrophe.
3:09:07
beach
I remember stassats saying something like "In a new implementation of Common Lisp, threading should be considered from the start".
3:10:01
drmeister
Is it even possible? I thought that was the point of clojure - immutability is a simple fix.
3:10:07
beach
Whenever a scenario results in "... then there is a catastrophe", you need to make sure that the scenario can not happen.
3:17:00
beach
It is definitely not true that "If a generic function on an object is being evaluated in one thread when that object is changed in another thread - then there is a catastrophe".
3:19:06
beach
Maybe, but if you express yourself in this imprecise way, then you will invariable reach the wrong conclusions, such as "oh, then, whenever there is a modification to an object I need to lock it".
3:20:39
beach
For example, in SICL, I think I will be able to use CAS again for that case. The thread changing the object computes a new rack and then uses CAS to make sure that nobody else changed the object in the meantime.
3:21:08
beach
Combined with the fact that the rack contains all the information required to access the object (like the description of each slot), I think I can get away with it.
3:22:04
beach
Having said that, I also haven't thought through all the scenarios possible for SICL, but there is no rush for me. I don't have a working implementation yet.
3:23:19
drmeister
How would you use CAS in this case? I thought CAS was best for integral types. Are you thinking to check every slot of the rack to see if it was changed?
3:29:18
drmeister
I've also been working on logging the fastgf slow path from different threads - that's not working either for me at the moment.
3:29:45
drmeister
Every time I try slime in :spawn mode emacs locks up _hard_. I have to shut it down from another terminal.