lkml.org 
[lkml]   [2000]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectre: Changes in the sockets: SIGIO handling
    sct's stance on race conditions between close(), accept(), and sigwaitinfo()
    in sigio-based programs can be summed up as "Oh, don't worry about
    ghost events, you should be prepared for read() to return EWOULDBLOCK".
    This works for POLL_IN and POLL_OUT events. But Julian points out that
    it might be hard to ignore POLL_ERR and POLL_HUP events in the same way.

    Maybe we do need marker events for fd creation and/or deletion after all...

    sct, what say ye?

    - Dan "Chicken Little" Kegel

    Julian Anastasov <uli@linux.tu-varna.acad.be> wrote:
    > With current behavior, when we receive POLL_HUP we know
    > that the remote end closed its end of the connection. But what
    > if we can't wait remote end to close the connection and we close()
    > the socket, even after shutdown(fd,1). After our close() when the
    > fd is released and can be reused again it is still possible unread
    > events to stay in the rt queue (POLL_IN in this case). When we
    > create/accept new file descriptor (with the same value) and continue
    > to read the events (from the long long rt queue) using sigwaitinfo(),
    > we can dequeue unexpected notifications for the old file descriptor.
    >
    > For example:
    >
    > <-- POLL_IN for fd
    > sigwaitinfo(): POLL_IN for fd
    > read(fd)=100
    > // We remember that we can write(), so we try to write()
    > write(fd)=100
    > shutdown(fd,1)
    > // We wait remote end to close
    > // Here we expect POLL_IN but it is not received (after some
    > // timeout)
    > <-- POLL_IN for the listener enqueue
    > <-- POLL_IN/POLL_ERR enqueued after our last check of
    > the rt queue
    > // We decide to close(fd)
    > close(fd)
    > sigwaitinfo(): POLL_IN for the listener
    > fd = accept()
    > set fd FASYNC, ... (or inherited from accept)
    > sigwaitinfo(): POLL_IN/POLL_ERR for the old fd but we think it
    > is for the new fd. Not fatal, one extra read()=EAGAIN
    >
    > What if we receive POLL_ERR from old fd when the new fd is
    > in connecting state? We think the connection failed for the
    > new fd. FATAL!

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:4.719 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site