Re: A signal fairy tale

[Christopher Smith <x@xman.org>]

--On Wednesday, June 27, 2001 11:51:36 +0530 Balbir Singh 
<balbir.singh@wipro.com> wrote:
> Shouldn't there be a sigclose() and other operations to make the API
Wouldn't the existing close() be good enough for that?

> orthogonal. sigopen() should be selective about the signals it allows
> as argument. Try and make sigopen() thread specific, so that if one
> thread does a sigopen(), it does not imply it will do all the signal
> handling for all the threads.

Actually, this is exactly what you do want to happen. Linux's existing 
signals + threads semantics are not exactly ideal for high-performance 
computing. Of course, fd's are shared by all threads, so all of the threads 
would be able to read the siginfo structures into memory.

> Does using sigopen() imply that signal(), sigaction(), etc cannot be used.
> In the same process one could do a sigopen() in the library, but the
> process could use sigaction()/signal() without knowing what the library
> does (which signals it handles, etc).

If I understood Dan's intentions correctly, you could use signal() and 
sigaction(), but while the fd is open, signals would be queued up to the fd 
rather than passed off to a signal handler or sigwaitinfo(). Care to 
comment  Dan?

> Let me know, when somebody has a patch or needs help, I would like to
> help or take a look at it.

Maybe we can both hack on this.

--Chris