Race condition in reader about jscl HOT 5 OPEN

I have released a first web application using this technique (if interesting): https://github.com/hemml/TomoV
This is a complete in-browser Doppler tomography reconstruction application (for astronomical data), uses OMGlib, web workers, Storage API and, of course, JSCL :)

from 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.

from jscl.

The same situation with *macroexpander-cache* hash table, concurrent modifications of the table causes error in SBCL.

from jscl.

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.

from jscl.

What is your use case for multithreading with compiling JSCL?

from jscl.