On Mon, Nov 08, 1999 at 10:36:37AM -0800, Michael Graff wrote:
> 
> I have added to the -current kernel two new signals, and two new
> itimers.  The goal is to have user space threads packages stop using
> SIGALRM and/or SIGVTALRM.  This simplifies things in many ways, in
> that threads can use any signal (other than the new ones, SIGTHREAD
> and SIGTHREADV) and any itimer (other than ITIMER_THREAD and
> ITIMER_THREADV) and the threads package doesn't have to perform black
> magic, and HARD black magic, to route signals properly.
> 
> The changes are fairly minor, in that they just create a virtual timer
> and a real timer that only a threading package may use.  And the man
> pages mark them as "internal to NetBSD libraries" and warn that other
> libraries and applications should not touch them.
> 
> Ideally, if a program is multithreaded (using our pthreads, once we
> have it) applications and other libraries will not be allowed to use
> these timers/signals.
> 
> Comments?

I'm not shure if this is the right way to go. I want timers and signals for
my checkpointing library, too! And I'm shure there are good reasons for
processes to make good use of more than just one real timer.

chkpt could probably scavenge SIGTHREAD/ITIMER_THREAD, but then how to
implement threading with checkpointing?

What about the following idea: We enlarge the set of signals a process is
free to use (by, say, SIGUSR3, ..., SIGUSR8) and we increase the number of
itimers. And we implement a method to allocate (and free) signal/itimer pairs.

This would give much more flexibility than your proposal.

Lex