From owner-freebsd-arch Fri Dec 14 17:20:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 95D7637B419 for ; Fri, 14 Dec 2001 17:20:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011215012013.HEYO403.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sat, 15 Dec 2001 01:20:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA23107; Fri, 14 Dec 2001 17:14:32 -0800 (PST) Date: Fri, 14 Dec 2001 17:14:31 -0800 (PST) From: Julian Elischer To: Kenneth Wayne Culver Cc: arch@FreeBSD.ORG Subject: Re: KSEs and PTRACE/PROCFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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