lkml.org 
[lkml]   [2007]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 1/4] signalfd v1 - signalfd core ...
    On 3/7/07, Davide Libenzi <davidel@xmailserver.org> wrote:
    > Let's do this. How about you throw this way one of the case that would
    > possibly break, and I test it?

    Since you make such claims I assume your signalfd() implementation
    considers a signal delivered once it is reported to an epoll() caller.
    Right?

    This is not what you really want, at least not in all cases. A signal
    might be something you want to react on right away. Unless
    pthread_kill() is used it is delivered to the _process_ and not a
    specific thread. But this means if epoll() reports two events to one
    thread calling epoll() (one of them being a signal) and this thread is
    then stuck processing the other request, the signal is not handled
    even though there might be a second or third thread available to
    receive the signal. Those threads have the same right to receive the
    signal and the current implementation always looks for the
    best/fastest way to deliver the signal.

    This means to me that reporting the signal in epoll() does _not_ mark
    the signal as handled. Somehow (probably using the signalfd()
    descriptor) the thread must explicitly request the signal to be
    delivered. But if you do this the epoll() handling is fantastically
    racy if the signal is not blocked.
    -
    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: 2007-03-16 06:19    [W:0.021 / U:60.772 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site