Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Oct 1999 21:55:59 -0500 (EST)
From:      Chuck Robey <chuckr@picnic.mat.net>
To:        Julian Elischer <julian@whistle.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Threads goals  version II
Message-ID:  <Pine.BSF.4.10.9910312145020.29073-100000@picnic.mat.net>
In-Reply-To: <Pine.BSF.4.05.9910311817030.8816-100000@home.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Oct 1999, Julian Elischer wrote:

> 7/ Some well documeted scheme exists for handling signals and other async
>         events.

Would this possibly mean that if a signal isn't caught, it's action
reflects upon the entire process, but if it's caught, a thread-specific
handler catches it?  That would mean that the kernel is going to have to
be able to identify, when a signal comes in, both a process ID and
(because a signal may post against other than the active process, such as
a timer signal) a thread ID.

Or would an uncaught signal merely act on the active thread?

> 10/ Quick access to curthread and thread specific data.  We shouldn't
>        have to enter the kernel to get this.  This should also be true
>        for threads spread across multiple [lightweight] processes.

This is the my question (the other was an outgrowth), I guess, which is,
would /proc be modified, and then would ps report both on processes *and*
threads (maybe sorted, the make more sense)?

> 11/ Ability for the threads library to cancel/terminate a thread
>        blocked in the kernel.
> 
> 12/ Processorr affinity for threads.

It seems to me that it would be pretty likely that a thread would want to
bias this choice itself.  This is pretty closely identified with items 13
and 13A, isn't it?  I would be pretty surprised if significantly better
programs couldn't be written if a program could set it's own bias here.

If each thread could be given it's own small block of kernel data, then I
think that the rest could be done, right?  Are we trying to find a way to
do this with minimal kernel resources, is that it?

----------------------------------------------------------------------------
Chuck Robey                | Interests include C programming, Electronics,
213 Lakeside Dr. Apt. T-1  | communications, and signal processing.
Greenbelt, MD 20770        | I run picnic.mat.net: FreeBSD-current(i386) and
(301) 220-2114             |       jaunt.mat.net : FreeBSD-current(Alpha)
----------------------------------------------------------------------------





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9910312145020.29073-100000>