[quickjs-devel] Re: quickjs & threads

  • From: Koushik Dutta <koush@xxxxxxxxxxxxxxxx>
  • To: quickjs-devel@xxxxxxxxxxxxx
  • Date: Thu, 23 Jan 2020 10:56:01 -0800

Also note that even synchronization locks on the JSContext, QuickJS still
not thread safe (because it assumes it will only ever be called from the
same thread). From a previous email:

I'm using QuickJS in a multithreaded environment, where all access is
synchronized, so only one thread may be executing on the QuickJS runtime at
any given time. This works great, but I had to patch
out js_check_stack_overflow.

js_check_stack_overflow checks the JSContext stack_top (which is set only
at creation) against the current stack pointer. The stack pointer changes,
depending on which thread is being used. The comparison ends up being
erroneous and throwing a stack overflow. This is easily reproducible.

Possible fixes:
Trap all entry points into QuickJS, and update the stack pointer
accordingly before execution. There are too many.
Use thread local storage stack pointers. This might be expensive.
When QuickJS checks for stack overflow, do a sanity check, and compare last
known thread id, and update the stack top. This requires dependency on OS
internals.

I currently have the stack overflow check commented out in my fork.

Koush

On Thu, Jan 23, 2020 at 9:31 AM Alexander Mihalicyn <alexander@xxxxxxxxxxxxx>
wrote:

QuickJS code is not thread-safe. You could not use the same JSContext
structure in two threads simultaneously.

On Thu, Jan 23, 2020 at 8:57 AM JM <jeevhi@xxxxxxxxx> wrote:

Consider the scenario,

Launched Thread 1 {
        Create JSContext
        Eval JavaScript
         Save context somewhere
}

After sometime,

Launch Thread 2 {
            retrieve context saved from Thread 1
            Call some JS function using JSCall()
}

Since both the threads are not running simultaneously, I expected this
to work but it doesn't. Instead, JSCall() generates exception.

Any idea ?


Other related posts: