[lkml]   [2001]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A signal fairy tale
    Balbir Singh <> wrote:

    >Shouldn't there be a sigclose() and other operations to make the API

    No, plain old close() on the file descriptor returned by sigopen()
    would do the trick.

    >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.

    IMHO sigopen()/read() should behave just like sigwait() with respect
    to threads. That means that in Posix, it would not be thread specific,
    but in Linux, it would be thread specific, because that's how signals
    and threads work there at the moment.

    >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).

    Between sigopen() and close(), calling signal() or sigaction() on that
    signal would probably return EBUSY. A well-behaved program already
    looks for an unoccupied signal using sigaction (as Jamie Lokier
    points out), so they shouldn't try to reuse a signal in use by sigopen().

    - Dan

    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:10.132 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site