Race condition in reader
hemml opened this issue · comments
When executing read or read-from-string in multitasking environment, a race condition exists with jscl::labelled-objects, which is a global variable.
The following code is thread safe:
(let ((jscl::*labelled-objects* nil)) ;; workaround for JSCL reader race condition
(jscl::ls-read-from-string s))
I'm using jscl::ls-read-from-string when compiling lisp code on the host (with SBCL, for example), because quasiquotation symbols are not standardized yet and I have to write-to-string my code and read it with jscl::ls-read-from-string to get a proper representation for jscl::compile-toplevel.
The same situation with *macroexpander-cache* hash table, concurrent modifications of the table causes error in SBCL.
I think requiring a single thread in host is okay in this context. Especially because JS is also single threaded.
It's true that it would make easier to exploit async programming in JS but it would add lot of complexity.
What is your use case for multithreading with compiling JSCL?
I'm compiling CL code into JS and sending it to the browser to execute. The browser just evaluating everything it got from the websocket via eval(). This allows me to avoid any communication protocols. If I want to change something in the browsers state, I'm just sending a code which perform needed changes. Also, I can define functions in the browser (again, just by sending a (defun .... ...) compiled into JS) and use them for any internal UI logic. I'm developing the OMG library which simplifies all that tasks.
I can send CL code itself and execute it via eval in JSCL on browser-side, but JSCL compilation in browser is terrible slow. I believe that because JSCL reader is slow. So, I'm compiling the code on the backend. And stomping on race conditions sometimes.