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