This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Merge of nickrob-async-20060513 to mainline?
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 27 Sep 2006 10:09:38 +1200
- Subject: Re: Merge of nickrob-async-20060513 to mainline?
- References: <17652.63229.637451.185345@kahikatea.snap.net.nz> <20060830023335.GA6377@nevyn.them.org> <17653.930.196634.143646@kahikatea.snap.net.nz> <20060830040113.GA8257@nevyn.them.org> <17654.994.815362.897653@kahikatea.snap.net.nz> <20060830214257.GA5397@nevyn.them.org> <17688.59135.24869.397517@kahikatea.snap.net.nz> <20060926123757.GA9879@nevyn.them.org>
> Yes, this should work, though it seems cumbersome. When you've got
> a single thread, you don't need to pass actual data around an fd,
> just a marker "yes i'm ready now".
I don't quite follow, that's how the event loop works. Even user input
requires an fd through stdin_event_handler. There is a provision for other
events but currently only file events are used.
> Moving the call to waitpid out of linux-nat.c, and to a target
> independent file, is a mistake - presumably that's just how you got it
> to work quickly? That's related to why it doesn't work for threads.
> The vital line is "options ^= __WCLONE" in the loop in linux_nat_wait.
> Without __WCLONE, you'll never see a wait status from a thread; with
> it you'll never see a wait status from the main program.
Perhaps I can use __WALL as a catch all.
> Ideally you'd be able to reuse the signal handler logic (see the calls
> to sigprocmask and sigsuspend) and thus not have a millisecond latency
> and excessive spinning. That's actually a pretty important feature,
> because context switching to gdb every millisecond or so is going to
> really hurt performance of the debuggee.
OK, a bit more homework then.
Thanks
--
Nick http://www.inet.net.nz/~nickrob