Subject: Re: pthreads in userland, signals, and itimer.
To: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
From: Jaromir Dolecek <dolecek@ics.muni.cz>
List: tech-kern
Date: 11/09/1999 13:11:22
What do we gain with such flexibility ? That a program might use several
separate threading libraries at the same time ? Isn't it insane ?

Jaromir

Ignatios Souvatzis wrote:
> On Mon, Nov 08, 1999 at 04:47:14PM -0800, Michael Graff wrote:
> 
> [about Lex' proposal]
> 
> > I think this would be good too, but what do we do to get rid of
> > conflicting uses?
> 
> Let me outline the AmigaOS signals:
> 
> - There is a system call that allocates a signal number for a task
> - system calls that need to send back signal to the task get passed it
>   by the task, e.g., as part of a struct SignalSemaphore, or you pass it
>   in an IORrequest. 
>   For example, to get a timer event, you allocate a signal, pass it and
>   the timeout value in an IORequest to the timer.device. When the timeout
>   occurs, the task is sent the signal. Async I/O is done in the same way.
>   Sync I/O is Async I/O + auto-wait for the signal.
> - There is a call to free a signal once it is no longer used.
> 
> As the need for user-applicable signals is near, I suggest the following:
> 
> -a) we create a pre-process-variable, say an u_int32_t, for the allocated
>   user signals (we reserve a reange of 32 signal numbers for these numbers).
>   are 32 too much? maybe an u_int16_t is sufficient?
> 
> maybe better:
> -b) we use an u_int64_t, initialized to prevent usage of the system defined
>   signals
> 
> - we create a system call to allocate a bit in this variable, and pass it
>   back (hm, as a bit number or a mask?) 
> - we create a system call to free a bit in this variable.
>   an attempt to free a system fixed meaning signal (including SIGUSR1/2) 
>   will fail (EINVAL).
> - libraries that need a signal internally will allocate one; it won't conflict
>   with the fixed-meaning signals, or with SIGUSR(1|2).
> 
> Hm... maybe we can avoid special cases by haveing an u_int64_t per-process and
> pre-occupying  the fixed-meaning signals.
> 
> These signal numbers are strictly pre-process. That is, if p1 needs to send a
> signal to p2, p2 has to tell it what the number is.
> 
> * Option: don't make this a system call, but just a standard library function.
> 
> Regards,
> 	-is
> 


-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
"The only way to get rid temptation is to yield to it." -- Oscar Wilde