[lkml]   [2001]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A signal fairy tale
    --On Wednesday, June 27, 2001 11:51:36 +0530 Balbir Singh 
    <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:55    [W:0.020 / U:303.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site