Date: Fri, 6 Feb 2004 14:25:34 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: John Polstra <jdp@polstra.com> Cc: freebsd-threads@freebsd.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext Message-ID: <Pine.GSO.4.10.10402061413580.19996-100000@pcnet5.pcnet.com> In-Reply-To: <Pine.GSO.4.10.10402061200100.16647-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402061413580.19996-100000>