Messages in this thread |  | | Date | Mon, 16 May 2011 11:13:18 +0200 | | From | Tejun Heo <> | | Subject | Re: waitpid(WNOHANG) should report SIGCHLD-notified signals [Re: [PATCH 09/11] job control: reorganize wait_task_stopped()] |
| |
Hey, again.
On Sun, May 15, 2011 at 07:47:22PM +0200, Jan Kratochvil wrote: > > But, the current WNOHANG wait is racy. It's unlikely but definitely > > possible for WNOHANG to fail when it's expected to succeed (not the > > above case but more convoluted ones). > > OK, so FYI it breaks current GDB.
That might be true but the race cases are very obscure. Not sure whether the race conditions could actually affect ptracer. With SEIZE, it won't, I think.
> > But, just out of curiosity, is there any reason the ptracer itself > > should be doing something other than waitpid() while tracee is > > running? It's not like ptrace requests can be issued during that time > > and sleeping waitpid() is way saner mechanism to wait for tracee > > events than signal. > > If the debugger wants to be single-threaded ("poll() model", not "threads > model") and it wants to communicate with user and examine debuggee symbols and > memory data it cannot use sleeping wait. GDB is single-threaded and it > supports `set target-async 1': info '(gdb)Background Execution'
I don't think target-async is necessarily related. It doesn't really matter whether the execution per-se is async or not. The ptracer can be a separate thread regardless and the interlocking can be added on top (or not).
Anyways, I would recommend using sleeping wait(2)'s for ptrace event tracking. Well, signal notification would work but I think that would be much more error-prone and has much higher chance of being fragile.
Thanks.
-- tejun
|  |