From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 11:26:23 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1DEF16A4DC for ; Fri, 6 Feb 2004 11:26:23 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D9A43D72 for ; Fri, 6 Feb 2004 11:25:54 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i16JPYfo023362; Fri, 6 Feb 2004 14:25:34 -0500 (EST) Date: Fri, 6 Feb 2004 14:25:34 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Polstra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 19:26:23 -0000 On Fri, 6 Feb 2004, Daniel Eischen wrote: > > Well, we are implementing POSIX API's so if there is an existing > standard for pthread_get_suspended_thread_context(), we'll add it. > Or if there is some de-facto standard that other vendors seem > to be implementing we can do that. I've even made the offer to > the -java folks to add whatever they need to get the JDK to > work, and so far all they really needed was suspend/resume > and a way to get thread attributes (stack). One more take on this... With libpthread (and libthr), threads can be blocked in the kernel and the libraries don't currently have any way to get to their registers. And with libthr and scope system threads in libpthread, threads can be running outside the current threads scheduling domain. Suspension in those cases doesn't work or is not yet implemented. We would need some help from the kernel to do it properly. Plus even if you suspend a thread in the kernel, you still don't have access to its registers so the kernel would also have to provide a way to get them. The libraries might be able to use a special signal to interrupt those threads, then their contexts would be available. But the application could always do the same (and it seems from the PR that is the case in this instance). -- Dan Eischen