--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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:17 EST