[lkml]   [2002]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] O(1) sys_exit(), threading, scalable-exit-2.5.31-A6

On Mon, 19 Aug 2002, Dave McCracken wrote:

> In looking at the code I was wondering something. What happens to the
> real parent of a ptraced task when it calls wait4()? If that's its only
> child, won't it return ECHILD?

hm, so this could be fixed by iterating over the ptraced tasks as well
when doing a wait4.

the problem is that the debugger wants to do a wait4 as well, to receive
the SIGSTOP result. Now if the original parent 'steals' the wait4 result,
what will happen?

this whole mess can only be fixed by decoupling the ptrace() mechanism
from signals and wait4 completely, it's a nasty relationship that infests
both the kernel and userspace code [check out strace.c once to see the
kind of pain it has to go through to isolate ptrace events from other

I'm not quite sure whether this is possible, how deeply do ptrace
applications depend on a real SIGSTOP signal interrupting the task? Would
it be equally good if it was a different interruption/signalling method
that did this? [with a few minor and straightforward cleanups to entry.S i
think we could use a task ornament flag for ptrace interruption. This
would result in a few orders better behavior on all fronts.]


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.106 / U:1.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site