lkml.org 
[lkml]   [2001]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A signal fairy tale
--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/

\
 
 \ /
  Last update: 2005-03-22 12:55    [from the cache]
©2003-2011 Jasper Spaans