[lkml]   [2003]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: select for UNIX sockets?

    > Since I was an initiator of this topic on one of the Polish Linux groups
    > I'd like to explain some issues. We've been porting some larger piece of
    > software from Solaris to Linux and problem has arisen. Below is
    > corrected
    > example (with errors checking after function calls), where isolated
    > problem
    > is presented. I hope this will cut off any suggestions that some of
    > function
    > calls return errors which aren't detected and handled.
    > An experiment shows that there is no error occurrences while running
    > these
    > examples on Linux and sender blocks on sendto() (after sending
    > _successfully_
    > some datagrams to the receiver) when select() returns with ready to
    > write descriptor.
    > The same example works _correct_ on Solaris and QNX (sender blocks on
    > select() call and _never_ on sendto() ).
    > Question is:
    > Am I doing something wrong or maybe there is a bug in select() function
    > under Linux?

    You are doing something wrong. You are using 'select' along with blocking
    I/O operations. You can't make bricks without clay. If you don't want to
    block, you must use non-blocking socket operations. End of story.

    Just because 'select' indicates a write hit, you are not assured that some
    particular write at a later time will not block. Past performance does not
    guarantee future results.

    Suppose, for example, a machine has two network interfaces. One is very
    busy, queue full, and one is totally idle, queue empty. What do you think
    'select' for write on an unconnected UDP socket should do? If you say it
    should block, then it can block forever even if there's plenty of buffer
    space on the network card you were going to send to. So, it can't block, it
    must indicate writability.

    Now, tell me what a blocking UDP write should do if the buffer is full.
    Should it return success but drop the packet silently? Does that seem right
    to you?

    You have any number of sane choices. My suggestion is that you make the
    socket non-blocking and treat an EWOULDBLOCK return as equivalent to
    success. You can additionally take it as a hint that the packet will be as
    if it was dropped.


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