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