Closed Bug 426529 Opened 16 years ago Closed 12 years ago

enable jsdb to survive scatter

Categories

(Core :: JavaScript Engine, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: timeless, Assigned: timeless)

References

Details

Attachments

(1 file)

Attached patch draft (survives)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.
Depends on: 378918
> 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
Assignee: timeless → nobody
Component: Venkman JS Debugger → JavaScript Debugging APIs
Product: Other Applications → Core
QA Contact: venkman → jsd
Assignee: nobody → timeless
Component: JavaScript Debugging/Profiling APIs → JavaScript Engine
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.

Attachment

General

Creator:
Created:
Updated:
Size: