Subj : Re: JS_HandleTrap unhandled exception
To   : netscape.public.mozilla.jseng
From : Mike Moening
Date : Thu Mar 31 2005 11:19 pm

Ok...  Even IF I managed to lock the trap and watchpoint lists (which
are...oh rats...at the runtime level) I still don't think it will work
unless the JSHandleTrap function becomes more forgiveing and returns
JSTRAP_CONTINUE when FindTrap returns NULL because the trap was cleared.
That is unless the JSOP_TRAP is also taken out when JSClearTrap is called
(didn't have time to check this but I doubt it)

The debug controller we are using is meant to be fully multi-threaded.  i.e
as many debuggers as you want as long as they are each attached to a separt
context.
Must embedders go the MT way.  We really want to support that.

I think I could pretty easily make this baby thread safe if you don't mind
me making the changes...
:-)


"Brendan Eich" <brendan@meer.net> wrote in message
news:d2ih4j$nkq2@ripley.netscape.com...
> Mike Moening wrote:
> > I figured out the problem.
> >
> > Confutious say:
> > It is better to use JS_ClearTrap than to use JS_SetTrap to clear a
trap...
> >
> > Doh!
>
> Also, did you say "other thread"?  The JS debugger API is designed to be
> called from a single-threaded debugger, or a one-thread at a time
> debugger, or a debugger that is carefully multi-threaded with its own
> locking layer above the jsdbgapi.c code, which you'll notice does not
> lock critical sections, e.g. for rt->trapList access and update.
>
> /be

.