jbarnette / johnson

Johnson wraps JavaScript in a loving Ruby embrace.
http://github.com/jbarnette/johnson/wikis
466 stars 33 forks source link

"Johnson is not thread safe" #28

Open tomtaylor opened 14 years ago

tomtaylor commented 14 years ago

I'm getting the following error thrown inside when trying to run sspinc/readability (which uses Harmony and Johnson) from inside Rails:

"Johnson is not thread safe"

Readability works on the first call to it, but subsequent calls to the same application throw that error. If I restart Mongrel and try again, it works once, but not after that.

AFAIK, Rails shouldn't be threading, so I'm a bit confused as to what's going on here.

Any suggestions?

Thanks a lot,

Tom

smparkes commented 14 years ago

A lot of things in Ruby use threading, even things as simple as net/http (for timeouts, in that case). The error message you're seeing is because Johnson has detected that's it's being called from a different thread than it expects, which is really going to make SpiderMonkey unhappy if it tries to garbage collect.

You could go into that part of the code in Johnson and dump a list of threads: I'm pretty sure you'll find there are more than one.

matthewd commented 13 years ago

I think that check could actually be changed... I think last time I investigated, I decided Mongrel seemed to be handling each request in a new thread (which seems fair enough).

A Rack-level lock will prevent more than one such thread from running at once, which would theoretically satisfy our restriction -- which is technically "SpiderMonkey must see a consistent stack". I use ruby-mozjs with Mongrel using such a "trust the caller to not cross threads" approach, and it seems to be stable enough.

Perhaps we could provide an explicit means for a thread to acquire a "SpiderMonkey lock", then return it, for when that's what's needed... if you call something without acquiring it, the current perma-lock behaviour kicks in.