freenode/#clasp - IRC Chatlog
Search
2:39:56
drmeister
I'm thinking more that the machinery for making symbol bindings thread safe isn't itself thread-safe.
2:40:53
drmeister
Since _Bindings wasn't atomic it was possible that it could be set by two threads in a race condition - that would lead to weird errors not unlike we are seeing.
2:41:49
drmeister
it's by no means clear that this is the problem but compile-file-parallel could expose a problem because it's a bunch of threads that startup and end at about the same time.
2:45:04
drmeister
The _Binding slot stores a size_t variable that stores an index into a thread local vector that stores bindings for symbols
2:46:01
drmeister
IIRC the first time a thread binds a dynamic variable the _Binding slot is set and that is the symbols index for life.
2:47:34
drmeister
The errors that we have been seeing when compile-file-parallel fails are this variable is unbound or that variable is unbound IIRC
2:49:24
drmeister
I've changed the _Binding to an atomic variable and I'm going to put in a print statement that will print if a race condition is ever detected.
2:50:02
drmeister
I'll have it do the right thing - but print a message - then we can watch for that message.
3:24:27
drmeister
I printed the _Binding of symbols as they are assigned - and it's very possible that there is a race condition...
3:29:19
drmeister
Once the compiler starts somewhere around line 40 there are many more symbols bound.
3:31:50
drmeister
Here I printed the thread id - there are threads racing to bind symbols at the same time.
3:43:47
drmeister
! WARN WARN WARN !!!! ANOTHER THREAD SET A SYMBOL _Binding slot to 79 before we could set ours to 80!!!!
3:45:03
drmeister
! WARN WARN WARN !!!! ANOTHER THREAD SET A SYMBOL _Binding slot to 122 before we could set ours to 123!!!!
6:42:41
drmeister
Everyone - I pushed to the 'work' branch a version of clasp that I think fixes this very random problem with compile-file-parallel.