Closed
Bug 426529
Opened 16 years ago
Closed 12 years ago
enable jsdb to survive scatter
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: timeless, Assigned: timeless)
References
Details
Attachments
(1 file)
66.07 KB,
patch
|
Details | Diff | Splinter Review |
with this patch you can perform operations like: f=function(){};t=function(){throw(1)};scatter([f,t]);quit() in js> under jsdb without dying. it's not perfect and it isn't ideal, but it doesn't die. personally, i'd like to have js tell me before it asserts that there are no cx's left in a thread, because otherwise i'm stuck using code similar to this patch, which really sucks. note that jsd w/ this changeset becomes essentially single threaded, whenever anything needs to operate, it locks the debugger long enough to perform the simple task, this shouldn't be an issue for most people as earlier jsd was likely to just cause interesting forms of death. jsd does not yet support per thread jsdcontexts (a feature MikeM added) and as such it is still buggy as can be seen by the XXX in jsdb's GetStackFrame code. Fixing that XXX probably means introducing jsd to mikem's new world (which is fine, but perhaps I could do that in a later patch). I updated some code to use JS_GetInstancePrivate. obviously some of this code isn't the cleanest. I will probably at some point get rid of a number of the JS_ASSERTs and replace them w/ runtime errors and returns, as a number of them are perfectly legal runtime events. the print()s in debugger.js are because i'm still chasing how to get the debugger to fully handle events from the scatter()d threads. the null handling in debugger.js is real, as the called code can really return null (throwing exceptions at the debugger is really not a good thing). I'm switching from new Foo() to Foo() for some of the debugger, but this was a recent change and i haven't fixed everything (this inconsistency is easily spotted in the diff). the 10 frame limit in debugger is temporary and was for testing some infinite recursion cases, it should go away. the jsd_xpc changes here are only because the diff was for the entire directory. for people curious about jsd_xpc and threadsafety, I have another patch (peller) which I'll post into some other bug once I manage to finish this work.
Comment 1•16 years ago
|
||
> personally, i'd like to have js tell me before it asserts that there are no
> cx's left in a thread, because otherwise i'm stuck using code similar to this
> patch, which really sucks.
What part sucks? I see a bunch of new code in jsdb.c, but I don't know how much of the new code is necessary anyway (to make it thread-safe) and how much is specifically attributable to JSAPI orneriness.
Btw, this boilerplate:
#ifndef JS_THREADSAFE
#define JS_BeginRequest(cx) void(0)
#define JS_EndRequest(cx) void(0)
#endif
isn't necessary if you're using the latest JS from trunk. Those functions are always defined now (they are no-ops in a non-JS_THREADSAFE build).
yeah, i know about the boilerplate. the clearrequest stuff needing to be done constantly just because i can't know when a thread is about to die is the problem, w/o it i could simply use the standard begin/endrequest
Updated•15 years ago
|
Assignee: timeless → nobody
Component: Venkman JS Debugger → JavaScript Debugging APIs
Product: Other Applications → Core
QA Contact: venkman → jsd
Updated•13 years ago
|
Component: JavaScript Debugging/Profiling APIs → JavaScript Engine
Comment 3•12 years ago
|
||
scatter was removed
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•