[haiku-commits] Re: r39846 - in haiku/trunk: headers/os/kernel headers/private/debug headers/private/kernel src/kits/debug src/system/kernel ...
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 15 Dec 2010 18:03:30 +0100
On 2010-12-15 at 05:58:16 [+0100], Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> On 12/14/10, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > No, I was thinking of having that in DebuggerInterface. Either there would
> > be
> > a separate thread or GetNextDebugEvent() would do that from time to time.
> > The
> > interface wouldn't change, save for the additional event(s) you already
> > added.
>
> In that case it seems to make more sense to implement the polling
> portion of it in TeamDebugger ; DebuggerInterface currently doesn't
> keep any information about the active thread list so it'd have to
> maintain a duplicate copy of the thread information TeamDebugger's
> already keeping in its fTeam member in order to be able to do the
> comparisons needed to see if anything's changed, which seems
> unnecessary. A thread off TeamDebugger would easily be able to access
> that information safely and just poll using DebuggerInterface's
> GetThreadInfos() call. Proof of concept patch attached for review.
The reason for doing that in DebuggerInterface is that this is the component
that abstracts the connection to the debugged program and from Debugger's
point of view name changes are just debug events from the debugged program.
My intention is to eventually turn DebugInterface into an interface and have
implementing classes not only for the currently implemented local debugging,
but also for remote connections. Polling over a slow connection (e.g. serial
line) is definitely not a good idea.
CU, Ingo
Other related posts:
