> >It would be useful if monitor information could also be returned, either in
> >this command or in another, ie list of monitor held and monitors being
> >waited on.
> >
> >
>
> Good suggestion. We'll provide support for this.
this is possible in JDI, in fact the current example jdb supports it. it
will be fairly easy to plug this in.
> >continue to run. It would, as ever, be useful to be able to choose what the
> >other threads do.
> >
>
> Do you mean you want debugger commands that suspend or activate threads
> independently of debuggee logic? If you do and that's possible, we should
> provide the commands.
>
> Amit, your thoughts?
yes that's possible. of course, if you arbitrarily suspend the
VM/thread(s) at any time, the vm is in an inconsistent state, and you
can't do nice things like execute methods (which you *can*, if you're on
a breakpoint)
i have a question: how should one identify threads? some options come to
mind:
1. enumerate the current threads using a command like "threads" in the
current jdb, and then use the ID returned (1, 2, 3..) to operate on the
thread. pitfall: it's not necessary that the IDs remain the same each
time you run the app, depending on the order they are created. also, if
the vm is not suspended, new threads might keep on being created, that
might mess up your numbering.
2. use thread "names". a good option if you make sure everybody "names"
their threads: but if vm needs to give default names to the threads like
Thread-2 etc, i'm not sure how good an idea this is. again, depending on
the way threads are created and whether you name your threads, you
might/might not be able to carry over the thread manipulation logic from
one vm to the other (ie over multiple invocations of the same app)
3. use unique "ids" that are associated with each object (23, 46, 67) in
the VM. "threads" lists all the threads but instead of numbering them,
simply prints the unique id associated with the thread. all user
manipulation will either refer to the threads by the ids, or will, eg,
click on the thread in the emacs frame, and jde will use the id of that
thread to converse with jdebug. pitfall: you can't carry over thread
mainp. logic over, as before. good thing: doesn't matter if new threads
keep getting created.
what do you think?
amit
