From 7baddcf950506d77792b595023716ba95c7d8afb Mon Sep 17 00:00:00 2001 From: Ingo Weinhold Date: Sun, 29 Jan 2006 00:58:09 +0000 Subject: [PATCH] Added TODOs regarding gdb blocking in some situations (e.g. on "info threads" when one of the team's threads is waiting uninterruptably on a semaphore). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16133 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- src/bin/gdb/gdb/haiku-nat.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/bin/gdb/gdb/haiku-nat.c b/src/bin/gdb/gdb/haiku-nat.c index 8c0ec4f291..142785d97d 100644 --- a/src/bin/gdb/gdb/haiku-nat.c +++ b/src/bin/gdb/gdb/haiku-nat.c @@ -733,7 +733,14 @@ haiku_stop_thread(team_debug_info *teamDebugInfo, thread_id threadID) } // wait for the event to hit our port - + + // TODO: debug_thread() doesn't guarantee that the thread will enter the + // debug loop any time soon. E.g. a wait_for_thread() is (at the moment) + // not interruptable, so we block here forever, if we already debug the + // thread that is being waited for. We should probably limit the time + // we're waiting, and return the info to the caller, which can then try + // to deal with the situation in an appropriate way. + // prepare closure for finding interesting events threadEventClosure.context = teamDebugInfo; threadEventClosure.thread = threadID; @@ -752,6 +759,10 @@ haiku_stop_thread(team_debug_info *teamDebugInfo, thread_id threadID) // We should check, whether we really got an event for the thread in // question, but the only possible other event is that the team has // been delete, which ends the game anyway. + + // TODO: That's actually not true. We also get messages when an add-on + // has been loaded/unloaded, a signal arrives, or a thread calls the + // debugger. return B_OK; }