Re: sending signals from xdd's

[Howard Chu <howard@harry.lloyd.com>]

  This is very analogous to a serial driver, which must send a SIGHUP signal to
  the process group controlled by this device.
  
  > Currently the only possibility I see to do the 1st is to fork a
  > new process (much like minixfs and modm0dev do) that is used to
  > send signals.
  
  It seems mandatory, indeed: if no process does I/O on the socket, the
  device driver functions will never be called, so you can't rely on these
  functions to post signals. Signals should be posted asynchronously, by
  another thread.
  
  > Is there another way (without a different process) to signal
  > different processes from a device driver?
  > 
  > Perhaps (as Juergen suggested some time ago) post_sig() should be
  > made available for device drivers through struct kerinfo?
  
  While it would be a Good Thing, it would not solve the problem indicated
  before, i.e. you still need another thread. But it would have the great
  advantage of allowing this thread to execute in kernel mode, so
  addroottimeout() would be usable...
  
Instead of requiring another thread, you could just install your own handler
in the vbl queue. Or perhaps we can add a queue internal to MiNT that's
processed at regular intervals. In either case you need to be able to call
post_sig in order for it to be useful. My patch to make Fselect work on the
standard BIOS serial ports just checks each port's buffers during vbl
processing and then calls wakeup or wakeselect as required. I suppose I could
also have implemented SIGIO there at the same time...

I guess a standard queue would be nice, have every driver that uses it set up
2 flags (e.g. read_ready and write_ready) that cause appropriate wakeup calls
to be made. We could even implement the Exceptional conditions for select.