[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] cdt debug threading model
|
>
> Hi,
>
> Could someone please explain the threading model used in the cdt debugger
> plugin? How many (and which) threads may run commands in the target
> debugger executable? Does the plugin run single-threaded or cooperatively
> threaded?
>
> I fear that I am seeing multiple threads attempting to access the
> debugger(gdb) and the UI at the same time...
I can explain for the CDI/MI/gdb part:
When an mi session is started 3 threads are created:
TxThread (Posting MI command to gdb)
RxThread (Receeving Parsing MI command from gdb)
EventThread (processing/dispatching events to any listeners)
Commands are posted in a queue monitor by the TxThread
miSession.postCommand(new MIBreakInsert("main"));
This will wake up the TxThread who will send the cmd to gdb,
it synchronizes by wait()ing, default is 10 secs..
1-break-insert main
If everything goes according to plan(gdb does not hang), the
receiving thread(RxThread) will wake up when a response comes in
1^done,bkpt=[...]
parses it and wakes the sleeping command(send a notifyAll()).
Perhaps, what you are seeing are commands timing out,
It is possible to force a complete sync by changing the timeout,
try to put it to a big number 100000000,
see MISession.java:MISession.setTimeout(); and change the value.
The debuguer will also start 2 other threads, monitoring
the output and the input of the inferior, the stream monitors.
