Hi Michael!

> > 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.
>
> I think this would be good too, but what do we do to get rid of
> conflicting uses?
>
> Also, the name cannot be *USR* since that seems like application space
> to me, rather than library or system space.  People get upset when
> SIGUSR1/2 are used in libraries already.
>
> I think threads are basic enough that they really need their own
> signals, if libc uses them.  For other things, I'd have no problem
> adding a few more timers/signals to help this, but we need to address
> the conflicting use problem first.
>
> For now, I'd like to get SIGTHREAD and the timers in the kernel.  I'd
> like to address the addition of other timers/signals as a separate
> issue.

I can very well understand your need for more timers and signals. But I think
just adding SIGTHREAD and thread timers is suboptimal. We should be looking for
a more general solution to the problem.

I think you didn't understand what I was trying to propose, but that's entirely
my fault because all the magic I had in mind is hidden in the sentence "And we
implement a method to allocate (and free) signal/itimer pairs."
I typed this in a hurry on my laptop at home connected via a costly phone line.

What I had in mind is similar to the AmigaOS stuff that Ignatios described (I
didn't knew the AmigaOS approach). Basically, we could create a system call
that allocates an unused timer, returning a signal number in the process'
private signal space (SIGUSR1 and SIGUSR2 are never returned by this system
call because they reside in the `traditional' signal space). An expiring timer
delivers this signal to the process. Another system call would free no longer
used timer/signal pairs (although I know, nobody would use this system call
anyway :-).

A threading library would just issue this system call and get a currently
unused timer/signal pair, install a signal handler and set the timer (in the
usual fashion). Threading libraries share (the new) timers with other libraries
and applications.


Take care,
Lex

-- 
Dr. Alexandre Wennmacher
Institut fuer Geophysik und Meteorologie         wennmach@geo.Uni-Koeln.DE
Universitaet zu Koeln                            phone  +49 221 470 - 3387
D-50923 Koeln                                    fax    +49 221 470 - 5198