bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext

[Daniel Eischen]

On Fri, 6 Feb 2004, John Polstra wrote:

> On 05-Feb-2004 Daniel Eischen wrote:
> > On Thu, 5 Feb 2004, Nick Barnes wrote:
> > 
> >> Somehow the GC must see the registers of each suspended thread, so
> >> that it can preserve any objects to which the registers point.
> >> Presumably the thread context is stored in some region which the GC
> >> treats as a root (e.g. on the thread stack, identified with
> >> pthread_attr_get_np, as you say).
> >> 
> >> A GC which has more information (e.g. the IP, the SP) may be able to
> >> use more sophisticated techniques (by using compiler-generated object
> >> liveness information, or by excluding dead areas of a stack segment
> >> from consideration as roots).  The limit of this is a system with
> >> close-coupled compiler, thread system, and GC, which can do "precise
> >> collection", including modifying the values of registers and stack
> >> slots.
> > 
> > I hear what you are saying, but it would seem that better
> > designed software would avoid the issue by keeping track
> > of any objects a thread has, using pthread_cleanup_push/pop,
> > mutexes, etc.
> 
> Maybe so, but that's not a useful attitude for an OS vendor to take.
> An operating system is a provider of services.  The services it
> provides had better be generally useful, or people will make other
> choices.
> 
> Like it or not, a lot of GC systems these days are built on legacy
> compilers (often GCC) that are not very malleable.  They can't

GNAT is built on GCC and uses native threads.  It has been
built onto GCC since 2.7.x (and probably prior).

> easily be made to do the bookkeeping you're asking for.  Or even if
> they could do that, they call into legacy libraries (such as libc)
> that were not compiled with such bookkeeping in mind.  JDK is the
> exception, not the rule.  It is the way it is because Sun, IBM and
> other companies have poured zillions of dollars into it.
> 
> If FreeBSD's native threads package can't provide a way to suspend
> all threads except the GC thread and then read the registers of the
> suspended threads, then the very widely-used Boehm conservative GC
> package won't be usable with FreeBSD's native threads.  Likewise,

To date, no-one has asked for the ability to read a suspended
threads registers.  With libpthread, you can get the thread
context via pthread_kill() which is what the PR was written
against.  I don't know whether you can do anything useful
with that context since it can be made via signalcontext(libc).

> those limitations would make it impossible to adapt Modula-3's threads
> package to take advantage of FreeBSD native threads -- which would
> be a big win performancewise.  I'm sure there are plenty of other
> examples.

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).

-- 
Dan Eischen