At 10:32 AM 7/8/99 -0700, Amit Kumar wrote:
>
>> >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
You mean each thread object?
>the VM. "threads" lists all the threads but instead of numbering them,
>simply prints the unique id associated with the thread. all user
Who generates the id? Are the id's persistant across sessions?
>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?
>
Option 3 sounds best, followed by option 1.
- Paul
