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

[John Polstra]

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

John