Date: Fri, 14 Dec 2001 17:14:31 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Kenneth Wayne Culver <culverk@wam.umd.edu> Cc: arch@FreeBSD.ORG Subject: Re: KSEs and PTRACE/PROCFS Message-ID: <Pine.BSF.4.21.0112141537100.17119-100000@InterJet.elischer.org> In-Reply-To: <Pine.GSO.4.21.0112141822540.3906-100000@rac1.wam.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Dec 2001, Kenneth Wayne Culver wrote: > I don't know how to do this, but would it be possible to allow a user to > somehow pick a thread if he/she wanted to? That would be most useful... > > Ken A Not very easily, but let's examine.... A user would want to trace a single thread in the program, but threads inside the userland part of the program are invisible to the kernel. It supplies some contexts to allow the userland scheduler to run things in parallel, but it doesn;t know which userland thread is being multiplexed onto which kernel thread. The kernel threads are 'created' when the program enters the kernel, and 'destroyed' when the system call completes. (not really, they are cached) so one thread in userland will hop from one kernel thread to another at great speed. The kernel actually has ACCESS to a key that might indicate the user thread running (this just occured to me) (the syscall return status block shuld be 'per user thread'), but even using that, it doesn't know how to associate that number with a given thread. Now assuming we got past this, what would be the desired behaviour? One thread single steps and all others proceed at normal speed? all other threads suspended? what of threads in another KSE group? (different scheduler class) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0112141537100.17119-100000>