Yeah, that is a bit like my first suggestion, but puts the book keeping
responsibility on the user. I might go with that, as all my entry points
into quickjs are wrapped in synchronization locks anyways.
I tried out a quick thread local storage implementation but it was not
working properly, and I didn’t look too hard into it. Right now I have just
removed the check altogether.
On Wed, Nov 13, 2019 at 2:27 AM Sam Hocevar <sam@xxxxxxxxxxx> wrote:
On Sun, Nov 10, 2019, Koushik Dutta wrote:
I'm using QuickJS in a multithreaded environment, where all access isat
synchronized, so only one thread may be executing on the QuickJS runtime
any given time. This works great, but I had to patchchanges,
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
depending on which thread is being used. The comparison ends up being
erroneous and throwing a stack overflow. This is easily reproducible.
Just FYI, I ran into a slightly similar issue because my JS context is
constructed on a different thread than the “main” JS thread. My fix was
to add a new void JS_TrackCurrentThread(JSContext *ctx) function that the
user needs to call before any QuickJS call. This works great for me because
despite the multithreaded environment I only have one active JS thread, so
it may or not be ideal for you.
Regards,
--
Sam.
