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
    Balbir Singh <balbir.singh@wipro.com> wrote:

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

    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 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    [W:0.020 / U:90.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site