Professional Web Applications Themes

Help with strange recvfrom and recvmsg problem - UNIX Programming

I'm having a problem with recvfrom and recvmsg on linux. The problem is as follows: immediately after poll returns with a POLLIN event on the socket FID, I call recvfrom or recvmsg with the MSG_PEEK flag set. I expect either to immediately return with an indication of how much data is available. The problem is that they are blocking even though poll just indicated that data was available. As far as I know, the only way the recv functions can block when the MSG_PEEK flag is set is if there is, in fact, no data available. The weird thing is ...

  1. #1

    Default Help with strange recvfrom and recvmsg problem

    I'm having a problem with recvfrom and recvmsg on linux. The problem
    is as follows: immediately after poll returns with a POLLIN event on
    the socket FID, I call recvfrom or recvmsg with the MSG_PEEK flag set.
    I expect either to immediately return with an indication of how much
    data is available. The problem is that they are blocking even though
    poll just indicated that data was available. As far as I know, the
    only way the recv functions can block when the MSG_PEEK flag is set is
    if there is, in fact, no data available. The weird thing is that this
    problem seems to randomly occur after 150,000 to 500,000 messages have
    been received. Using gdb I've verified that the scatter-gather
    information is correct (pointers are valid and sizes are correct) and
    poll did, in fact, return indicating a POLLIN event. I've also
    verified that the FID in the events struct for poll is the same FID
    being sent to the recv function.

    I'm about to punt and bring up the kernel debugger to see what is
    going on, but before I do that, I wanted to find out if anyone else
    has seen a similar problem, and if so, was there a fix for it?

    Thanks in advance for any information anyone can provide.
    Mike Guest

  2. #2

    Default Re: Help with strange recvfrom and recvmsg problem

    In article <google.com>,
    Mike Lynch <com> wrote: 

    For various reasons, select() or poll() will sometimes indicate that a
    socket is readable when it isn't really. The simplest case of this is when
    multiple threads or processes are polling the same socket simultaneously;
    they'll all be woken up, but only the first one will get the data.

    The simplest solution is to make the socket non-blocking. If the recv()
    fails with EWOULDBLOCK, go back to poll(). If it keeps returning
    immediately, *then* I'd worry that something is wrong.

    --
    Barry Margolin, mit.edu
    Level(3), Woburn, MA
    *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
    Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
    Barry Guest

  3. #3

    Default Re: Help with strange recvfrom and recvmsg problem


    "Mike Lynch" <com> wrote in message
    news:google.com...
     

    You can't make bricks without straw. If you don't ever want to block,
    you *MUST* use non-blocking sockets.

    DS


    David Guest

  4. #4

    Default Re: Help with strange recvfrom and recvmsg problem

    On 2003-11-20, Mike Lynch <com> wrote: 

    If you are sure that no other thread reads from the same socket then I
    can offer you to check carefully that POLLIN event was actually returned
    by poll. A while ago I had exactly the same problem but it appeared that
    I was checking before the call to poll was done and what I saw was just
    a leftover from previous poll.

    Andrei
    Andrei Guest

  5. #5

    Default Re: Help with strange recvfrom and recvmsg problem

    Barry Margolin <mit.edu> wrote in message news:<uU7vb.14$level3.com>... 
     

    The FID is being used by a single thread only.
     

    As a test, immediately after getting the POLLIN event, I call poll
    again just before my call to recvmsg, it immediately returns with
    another POLLIN (I set revents to 0 before the call to poll) and then I
    call recvmsg with MSG_PEEK set and it blocks.
    Mike Guest

  6. #6

    Default Re: Help with strange recvfrom and recvmsg problem

    "David Schwartz" <com> wrote in message news:<bpjhja$263$webmaster.com>... 
    >
    > You can't make bricks without straw. If you don't ever want to block,
    > you *MUST* use non-blocking sockets.
    >
    > DS[/ref]

    I don't care if the call blocks. What I care about is that fact that
    I'm being told that data is available (via poll) and when I go to read
    it (via recvmsg) there is no data available.
    Mike Guest

  7. #7

    Default Re: Help with strange recvfrom and recvmsg problem

    Andrei Voropaev <ru> wrote in message news:<bpkr88$1oq3if$news.uni-berlin.de>... 

    I have verified (using gdb) that no other thread is reading from the
    socket and the poll is, in fact, returning with a POLLIN event. As a
    matter of fact, just to verify that I have a POLLIN event, immediately
    before calling recvmsg, I redo the poll and it immediately returns
    with a POLLIN event also. So the calling sequence is literally:

    revents = 0
    poll (returns 1, gets POLLIN)
    Mike Guest

Similar Threads

  1. [PHP] strange new problem with IE
    By Jay Blanchard in forum PHP Development
    Replies: 2
    Last Post: September 11th, 01:41 PM
  2. Signals and recvfrom() behavior
    By Karl Robillard in forum UNIX Programming
    Replies: 10
    Last Post: August 12th, 11:24 AM
  3. recvfrom returns with an error code of 14, EFAULT "Bad Address"
    By Chris Ritchey in forum UNIX Programming
    Replies: 6
    Last Post: July 8th, 09:44 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139