"Johnson is not thread safe" #28

Open
tomtaylor opened this Issue Jun 11, 2010 · 2 comments

Comments

Projects
None yet
3 participants
@tomtaylor

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

This comment has been minimized.

Show comment Hide comment
@smparkes

smparkes Jun 12, 2010

Collaborator

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.

Collaborator

smparkes commented Jun 12, 2010

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

This comment has been minimized.

Show comment Hide comment
@matthewd

matthewd Mar 31, 2011

Collaborator

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.

Collaborator

matthewd commented Mar 31, 2011

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.

@ghost ghost assigned matthewd Apr 13, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment