From owner-freebsd-arch Fri Dec 14 19:51:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id A37FF37B41A for ; Fri, 14 Dec 2001 19:51:54 -0800 (PST) Received: (qmail 3985 invoked from network); 15 Dec 2001 03:51:43 -0000 Received: from ken.yumyumyum.org (HELO there) (192.168.0.2) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 15 Dec 2001 03:51:43 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Kenneth Culver To: Julian Elischer Subject: Re: KSEs and PTRACE/PROCFS Date: Fri, 14 Dec 2001 22:51:56 -0500 X-Mailer: KMail [version 1.3.1] References: In-Reply-To: Cc: arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011215035154.A37FF37B41A@hub.freebsd.org> 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 Friday 14 December 2001 08:14 pm, you wrote: > 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) well, I would think that the threads that don't rely on data from the currently stopped thread should stop, just the thread that I want to stop should stop, along with any threads that rely on data from that thread... is that possible? I would also think that threads in a different KSE group could keep running given the same conditions.... as long as no threads there rely on data from the thread you stopped, I guess they could keep going... Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message