Yes, it looks like it was down to too many persistent handles, and not
quite enough scoping/disposal. Hasn't crashed out since making a few
changes along those lines, and going through the embedders guide and
source examples with a keener eye on the nature of context scopes and
_exactly_ what 'Persistent' implies for the garbage collector... I
think some handles were sticking around past their shelf-life and
causing trouble the next time they came into general scope. Looks (and
feels) much cleaner than the original code now, which is good news.

Hopefully that's the end of that! Plenty of useful plans for this now
it seems to have stabilised (have already outfitted our curl library
wrapping with support for proxy pac files, for example, and will
probably add drop-in support for user-defined functions into one of
our more flexible data parsing modules).

Regards...


On May 21, 12:15 am, Stephan Beal <[email protected]> wrote:
> On Wed, May 20, 2009 at 4:54 AM,  <[email protected]> wrote:
> > On the C++ side IsEmpty() is just checking if the handle internal val_
> > is == 0, which is effectively equivalent to a null pointer when used
> > in that context.
>
> Be aware that they're not equivalent JS-side, though. Dereferencing an
> IsEmpty() handle will crash your app, whereas dereferencing v8::Null()
> must(?) work in order for toString() to work on null values.
>
> > permanent fix, or some temporary bit of luck. (It's a little bit
> > 'voodoo', which I always hate -- I prefer to know _exactly_ why it is/
> > isn't working)
>
> Amen. i've had to fight with object/call ordering several times, only
> to stumble across a particular ordering which appears to work, without
> understanding why other orderings don't work. :/
>
> Back to your code:
>
>  // create new handle scope and default context
>    v8::HandleScope handle_scope;
>    v8::Persistent<v8::Context> execution_context;
>    v8::Persistent<v8::Value> global_object =
> v8::Persistent<v8::Value>::New(v8::Handle<v8::Value>());
>    v8::Persistent<v8::ObjectTemplate> global_template =
> v8::Persistent<v8::ObjectTemplate>::New(v8::ObjectTemplate::New());
>
> Is Persistent<> really necessary there? The example v8 shell (off of
> which i base my own code) says:
>
>        v8::Handle<v8::ObjectTemplate> global = v8::ObjectTemplate::New();
> ...
>         v8::Handle<v8::Context> context = v8::Context::New(NULL, global);
> ...
>         v8::Context::Scope context_scope(context);
>
> note the different order of creation of the Context and Global object, too.
>
>
>
> > Much as I'd like to jump up the compiler chain so I wasn't having to
> > use a custom header, we have a million-line codebase that we support
> ...
> > to get things working there, but it's not a high priority -- it's not
> > like there's anything actually wrong with VS2003. If anything VS2008
> > is more irritating due to the endless warnings begging you to use
> > their own 'secure' [aka: slow] STL features)
>
> i've you're not heavily using templates, e.g. partial specializations,
> then VS2003 should be okay, i would think. In my limited experience
> with MS compilers, templates (which i make heavy use/abuse of) were
> often problematic.
>
> --
> ----- stephan bealhttp://wanderinghorse.net/home/stephan/
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---

Reply via email to