stability?
Steven Parkes
thinking of both ffi and johnson. Since johnson requires less work, I
looked at it first.
Definite stability issues. GIven Mathew's recent work, it looks like
it's around gc.
Any feel for how bad this issue is? Is it likely addressable? Or one
of those "we don't really know what the f is going on ..."
Matthew Draper
Hi!
On Thu, 2009-10-08 at 19:31 -0700, Steven Parkes wrote:
> I've been looking at getting env.js hosted under ruby/spidermonkey ...
> thinking of both ffi and johnson. Since johnson requires less work, I
> looked at it first.
Less work does carry a certain appeal. :)
> Definite stability issues. GIven Mathew's recent work, it looks like
> it's around gc.
On master? At the moment I think the only places I know of that'll
segfault are from passing unexpected classes to internal functions, and
a few (again, fairly internal) Ruby functions that can't safely raise
exceptions.
If you're seeing segfaults, that's useful information in itself -- more
details, even better. :)
Alternatively, if you're seeing misbehaviour other than segfaults,
what's happening?
> Any feel for how bad this issue is? Is it likely addressable? Or one
> of those "we don't really know what the f is going on ..."
We have a Known Issue with Ruby threads -- the playing around with the
call stack that Ruby does with setjmp/longjmp seems to make
SpiderMonkey's GC sad. The specific cause falls somewhat into the latter
category, though I have a theory or two.
That problem can be avoided, either by not using threads, or by just
disabling SpiderMonkey's GC.
All that said, I'll also note that while it's not as architecturally
elegant as Johnson and isn't being actively developed, I've had
ruby-mozjs running in production for some time, and don't remember the
last time I saw it segfault... certainly over a year ago.
Matthew
Steven Parkes
>> spidermonkey ...
>> thinking of both ffi and johnson. Since johnson requires less work, I
>> looked at it first.
>
> Less work does carry a certain appeal. :)
Yeah, though FFI does mean it should/could work with jruby.
> On master?
Not yet ... I've been working from the released gem. I'll switch to
repo. I think I need to make some small changes to support multiple
global objects/scopes anyway ...
> At the moment I think the only places I know of that'll
> segfault are from passing unexpected classes to internal functions,
> and
> a few (again, fairly internal) Ruby functions that can't safely raise
> exceptions.
Cool. To a first degree, I was just trying to get a feel for where
things stood.
> We have a Known Issue with Ruby threads --
Yeah. I kinda thought that might be the case. I'm not at all
surprised. I'm specifically trying to avoid threads at all. I
shouldn't be creating any right now, but eventually I need to do some
HTTP fetches and unless things have changed, I think net/http creates
threads. Yuck.
I figure threads would be the biggest portability issue, though I'm
still unsure about non-thread related GC issues. I did some playing
around with an FFI interface to v8; be cool if that could be an
alternative to SM, though there are serious issues there, not the
least that V8 doesn't have a C API (just C++, and they have things
that can't be easily wrapped).
Anybody try with tracemonkey? I know it got talked about, but hand't
seen any real experience ...
> All that said, I'll also note that while it's not as architecturally
> elegant as Johnson and isn't being actively developed, I've had
> ruby-mozjs running in production for some time, and don't remember the
> last time I saw it segfault... certainly over a year ago.
Thanks ... I'll keep that in mind.