[ On , October 17, 2000 at 13:49:11 (+0900), enami tsugutomo wrote: ]
> Subject: Re: Time to fix a 25 year old misdesign
>
> For me, it looks like the problem is that kernel reuses pid while it
> keeps a reference to struct pgrp (or proc) in other place.

Yes, this is indeed the root of the problem, though it's kind of the
other way around -- the kernel should free those references when the
process exits, just as it closes file descriptors when the process
exits.

Strictly speaking for SIGIO (and ISGURG) there's no major problems known
with allowing them to be sent to unrelated or even non-existant processes.

If SIGIO had the semantics of SysVR4 SIGPOLL and would cause the process
to terminate then several changes would be necessary in the various
system calls which register interest in it being sent, etc.

Indeed it is only a very few drivers now which incorrectly preserve a
copy of "struct proc *" in their "struct softc".  If these were pushed
up and recorded in the file descriptor entries, just as they are now for
sockets (and in the proc structure directly for ttys), then this
sillyness with SIGIO needing an extra driver interface would go away
quite elegantly indeed because there'd be no need to do the reference
accounting in the hardware driver layer.

The only trouble is in how to handle non-socket, non-tty, devices that
want to be able to deliver SIGIO since at the present time most of them
seem to be missing an upper-layer which could be notified of the
possibility of pending I/O and which could deliver the signal to those
processes which have expressed interest in receiving it.  I would think
that inventing new subsystems along the lines of the tty subsystem might
make the most sense, but this could be a non-trivial design effort.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>