timeout problem while using poll() - Unix

This is a discussion on timeout problem while using poll() - Unix ; Hi, i'm using poll() system call on 1 udp socket for both reading and writing, i'm setting timeout value but poll() never returns 0 which i need. instead of returnin 0, it returns 1 continuously and ready for writing (POLLOUT ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: timeout problem while using poll()

  1. timeout problem while using poll()

    Hi,
    i'm using poll() system call on 1 udp socket for both reading and
    writing, i'm setting timeout value but poll() never returns 0 which i
    need. instead of returnin 0, it returns 1 continuously and ready for
    writing (POLLOUT flag is enabled) , so i'm guessing, since it is never
    got block, timeout value resets all the time. what should i do?

    this is how i used in code,

    int timeout = 2000;
    while(1) {
    if ( (pret = poll(&pfd, 1, timeout)) < 0) {
    err_sys(1, "main()->poll");
    }
    if(!pret) {
    printf("timeout happens sometimes\n");
    break;
    }
    if(pfd.revents & POLLIN) {
    nread = udm_socket_read(buff);
    UCP_reply_handler(buff, nread,
    &first_ubi_dev);

    }
    if(pfd.revents & POLLOUT) {
    if(sendcmd) {
    if(sendcmd()) {
    sendcmd = NULL;
    }
    }
    }
    }

    Thanks.


  2. Re: timeout problem while using poll()

    Sinan writes:

    > Hi,
    > i'm using poll() system call on 1 udp socket for both reading and
    > writing, i'm setting timeout value but poll() never returns 0 which i
    > need. instead of returnin 0, it returns 1 continuously and ready for
    > writing (POLLOUT flag is enabled) , so i'm guessing, since it is never
    > got block, timeout value resets all the time. what should i do?


    You are asking poll() to wait until you are able to either read or write
    to the socket without blocking. Since apparently the network connection
    is having no trouble keeping up with your sending, you are always able
    to write, so poll() returns immediately.

    It sounds like this isn't what you want to be doing. What are you
    really hoping to achieve? You say "timeout", but what operation do you
    want to have a timeout for?

    >
    > this is how i used in code,
    >
    > int timeout = 2000;
    > while(1) {
    > if ( (pret = poll(&pfd, 1, timeout)) < 0) {
    > err_sys(1, "main()->poll");
    > }
    > if(!pret) {
    > printf("timeout happens sometimes\n");
    > break;
    > }
    > if(pfd.revents & POLLIN) {
    > nread = udm_socket_read(buff);
    > UCP_reply_handler(buff, nread,
    > &first_ubi_dev);
    >
    > }
    > if(pfd.revents & POLLOUT) {
    > if(sendcmd) {
    > if(sendcmd()) {
    > sendcmd = NULL;
    > }
    > }
    > }
    > }
    >
    > Thanks.


  3. Re: timeout problem while using poll()

    Sinan wrote:
    > i'm using poll() system call on 1 udp socket for both reading and
    > writing, i'm setting timeout value but poll() never returns 0 which
    > i need. instead of returnin 0, it returns 1 continuously and ready
    > for writing (POLLOUT flag is enabled) , so i'm guessing, since it is
    > never got block, timeout value resets all the time. what should i
    > do?


    > this is how i used in code,


    > int timeout = 2000;
    > while(1) {
    > if ( (pret = poll(&pfd, 1, timeout)) < 0) {
    > err_sys(1, "main()->poll");
    > }
    > if(!pret) {
    > printf("timeout happens sometimes\n");
    > break;
    > }
    > if(pfd.revents & POLLIN) {
    > nread = udm_socket_read(buff);
    > UCP_reply_handler(buff, nread,
    > &first_ubi_dev);


    > }
    > if(pfd.revents & POLLOUT) {
    > if(sendcmd) {
    > if(sendcmd()) {
    > sendcmd = NULL;
    > }


    Um, why the two "sendcmd()" calls there?

    > }
    > }
    > }


    On what stack(s) are you running? There is no protocol level flow
    control in UDP, so unless the stack has "intra-stack" flow control a
    UDP socket will _always_ be writable and as such poll() asked for
    POLLOUT will always return immediately.

    If you are using non-blocking, you might consider always trying your
    writes to the socket without doing a poll() first, and only poll()ing
    for POLLOUT if you get an EAGAIN on the UDP write call (as in the next
    time around your event loop). In that way you should (famous last
    words) be robust on both stacks with and without intra-stack flow
    control for UDP.

    Otherwise, if you know you will always be running on a stack without
    intra-stack flow control for UDP you can just not worry about
    poll()ing for POLLOUT at all.

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  4. Re: timeout problem while using poll()

    Rick Jones writes:
    >Sinan wrote:
    >> i'm using poll() system call on 1 udp socket for both reading and
    >> writing, i'm setting timeout value but poll() never returns 0 which
    >> i need. instead of returnin 0, it returns 1 continuously and ready
    >> for writing (POLLOUT flag is enabled) , so i'm guessing, since it is
    >> never got block, timeout value resets all the time. what should i
    >> do?

    >
    >> this is how i used in code,

    >
    >> int timeout = 2000;
    >> while(1) {
    >> if ( (pret = poll(&pfd, 1, timeout)) < 0) {
    >> err_sys(1, "main()->poll");
    >> }
    >> if(!pret) {
    >> printf("timeout happens sometimes\n");
    >> break;
    >> }
    >> if(pfd.revents & POLLIN) {
    >> nread = udm_socket_read(buff);
    >> UCP_reply_handler(buff, nread,
    >> &first_ubi_dev);

    >
    >> }
    >> if(pfd.revents & POLLOUT) {
    >> if(sendcmd) {
    >> if(sendcmd()) {
    >> sendcmd = NULL;
    >> }

    >
    >Um, why the two "sendcmd()" calls there?


    There isn't. He's using a stupid C trick of treating a function pointer as
    a boolean.

    It more correctly should be

    if (sendcmd != NULL) {
    if (sendcmd() != 0) {
    sendcmd = NULL;
    }
    }

    Assuming sendcmd is a pointer to a function returning int.

    scott

  5. Re: timeout problem while using poll()

    On Nov 7, 5:52*pm, Sinan wrote:

    > i'm using poll() system call on 1 udp socket for both reading and
    > writing, i'm setting timeout value but poll() never returns 0 which i
    > need. instead of returnin 0, it returns 1 continuously and ready for
    > writing (POLLOUT flag is enabled) , so i'm guessing, since it is never
    > got block, timeout value resets all the time. what should i do?


    You are getting precisely the behavior you are asking for. If this
    isn't the behavior you want, ask for the behavior you want. You didn't
    explain what behavior you wanted, so we can't really help you.

    You asked the implementation to wait up to a certain amount of time
    until either a read or a write was possible. A write was possible, so
    it stopped waiting. If you wanted it to wait, what did you want it to
    wait *for*?

    DS

  6. Re: timeout problem while using poll()

    Thanks, for the replies. Actually yes the behavior is kinda what i am
    expecting, i'm using linux and what i was really expecting is, the
    timeout value is not modified by the kernel when there is no real data
    on sockets send buffer, even the function returns for POLLOUT. i don't
    know the internals but there must be socket's buffer and kernel should
    consider whether it is filled and ready to be sent or not. yes sendcmd
    is pointer to function which return int, i need to check out sendcmd
    every poll returns and POLLOUT is set, because its global and can be
    set by other functions too, so sending data before poll() does not
    work for me, according to replies i can change the sendcmd pointer. i
    think i can use signals for timeout behavior but i want not to loose
    incoming packets even after timeout expires, thats actually why i
    tried timeout value in poll.

    Thanks.

  7. Re: timeout problem while using poll()

    On Nov 8, 1:35*am, Sinan wrote:

    > Thanks, for the replies. Actually yes the behavior is kinda what i am
    > expecting, i'm using linux and what i was really expecting is, the
    > timeout value is not modified by the kernel when there is no real data
    > on sockets send buffer, even the function returns for POLLOUT.


    Huh? What do you mean by "the timeout value is not modified"? The
    timeout is an input that tells 'poll' how long to wait. It can't be
    "modified" because it's not returned.

    You called 'poll' and asked it to wait for something that had already
    happened, so it returned immediately and told you that it had already
    happened. You cannot wait for something that has already happened.

    Again, what are you trying to do?

    > i don't
    > know the internals but there must be socket's buffer and kernel should
    > consider whether it is filled and ready to be sent or not.


    Are we talking about a send buffer or a receive buffer? What do you
    mean by "ready to be sent"? Sent over the network? Or sent to the
    application?

    You still haven't given us any idea what it is you're trying to do or
    why the correct behavior you are seeing isn't what you want.

    > yes sendcmd
    > is pointer to function which return int, i need to check out sendcmd
    > every poll returns and POLLOUT is set, because its global and can be
    > set by other functions too, so sending data before poll() does not
    > work for me, according to replies i can change the sendcmd pointer. i
    > think i can use signals for timeout behavior but i want not to loose
    > incoming packets even after timeout expires, thats actually why i
    > tried timeout value in poll.


    Why are you calling 'poll' with POLLOUT set? What are you trying to
    do? It doesn't make sense (usually) to set POLLOUT on a UDP socket, so
    why are you doing it? And why are you unhappy when this does exactly
    what it's supposed to do?

    DS

  8. Re: timeout problem while using poll()

    On Nov 8, 5:15 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
    > Rick Jones writes:
    > >Sinan wrote:




    > >> if(sendcmd) {
    > >> if(sendcmd()) {
    > >> sendcmd = NULL;


    >
    > >Um, why the two "sendcmd()" calls there?

    >
    > There isn't. He's using a stupid C trick of treating a function pointer as
    > a boolean.


    What do you mean with "C trick"? It's well defined.

    > It more correctly should be


    More correctly according to /your/ stylistic standards. Either way is
    equally correct according to C.

    > if (sendcmd != NULL) {
    > if (sendcmd() != 0) {
    > sendcmd = NULL;
    > }
    > }
    >
    > Assuming sendcmd is a pointer to a function returning int.


    Any type other than struct or union (or void) would do actually...

  9. Re: timeout problem while using poll()

    On Nov 8, 1:58*pm, David Schwartz wrote:
    > On Nov 8, 1:35*am, Sinan wrote:
    >
    > > Thanks, for the replies. Actually yes the behavior is kinda what i am
    > > expecting, i'm using linux and what i was really expecting is, the
    > > timeout value is not modified by the kernel when there is no real data
    > > on sockets send buffer, even the function returns for POLLOUT.

    >
    > Huh? What do you mean by "the timeout value is not modified"? The
    > timeout is an input that tells 'poll' how long to wait. It can't be
    > "modified" because it's not returned.
    >
    > You called 'poll' and asked it to wait for something that had already
    > happened, so it returned immediately and told you that it had already
    > happened. You cannot wait for something that has already happened.
    >
    > Again, what are you trying to do?
    >
    > > i don't
    > > know the internals but there must be socket's buffer and kernel should
    > > consider whether it is filled and ready to be sent or not.

    >
    > Are we talking about a send buffer or a receive buffer? What do you
    > mean by "ready to be sent"? Sent over the network? Or sent to the
    > application?
    >
    > You still haven't given us any idea what it is you're trying to do or
    > why the correct behavior you are seeing isn't what you want.
    >
    > > yes sendcmd
    > > is pointer to function which return int, i need to check out sendcmd
    > > every poll returns and POLLOUT is set, because its global and can be
    > > set by other functions too, so sending data before poll() does not
    > > work for me, according to replies i can change the sendcmd pointer. i
    > > think i can use signals for timeout behavior but i want not to loose
    > > incoming packets even after timeout expires, thats actually why i
    > > tried timeout value in poll.

    >
    > Why are you calling 'poll' with POLLOUT set? What are you trying to
    > do? It doesn't make sense (usually) to set POLLOUT on a UDP socket, so
    > why are you doing it? And why are you unhappy when this does exactly
    > what it's supposed to do?
    >
    > DS


    what i'm doing is i have a udp socket descriptor, i set POLLOUT and
    POLLIN to use same socket descriptor both sending and reading,
    according arguments given to software, i'm sending and/or listening,
    when message recieved, i process the content and send reply, and there
    is many clients that are sending messages to me simultaneously, i am
    not using select because it does not fit to my software's structure
    and i do not modify the code over beginning. by saying kernel does not
    modify timeout value is, i guessed or expected something like happens
    while using select(), select modifies timeval structure, that is what
    i was expected. it seems i need to re-think about my code's structure.
    Thanks for replies.

  10. Re: timeout problem while using poll()

    Sinan writes:

    > what i'm doing is i have a udp socket descriptor, i set POLLOUT and
    > POLLIN to use same socket descriptor both sending and reading,
    > according arguments given to software, i'm sending and/or listening,
    > when message recieved, i process the content and send reply, and there
    > is many clients that are sending messages to me simultaneously, i am
    > not using select because it does not fit to my software's structure
    > and i do not modify the code over beginning. by saying kernel does not
    > modify timeout value is, i guessed or expected something like happens
    > while using select(), select modifies timeval structure, that is what
    > i was expected. it seems i need to re-think about my code's structure.
    > Thanks for replies.


    This is kind of hard to understand. It would be a lot easier if you
    could use complete sentences, capitalization, and reread your article
    before posting, to see if it makes sense when read by someone who isn't
    familiar with what you're doing.

    Anyway: it's fine to read and write on the same socket. But these are
    independent operations. You seem to be under the impression that
    POLLOUT has to be set whenever the socket is being used for output at
    all. That's not correct. You set POLLIN if you want to wait until the
    socket has data to read (or until the timeout expires). You set POLLOUT
    if you want to wait until the system is able to send your data, but
    normally it's always able to send, so there's no wait needed and poll()
    would return at once. You're perfectly free to send() data without
    calling poll() with POLLOUT first. AFAIK, there is a chance that send()
    could block, but with UDP this would occur infrequently and probably
    only for a very short time.

    So the simplest way to do what you want would be something like:

    - poll with POLLIN
    - upon return, some data is ready to read (or it timed out)
    - read the data with recv()
    - send the response using send(). No need to poll here.
    - repeat.

    select() would work just as well here, by the way. The main advantage
    of poll() over select() is that it can poll an arbitrary number of file
    descriptors (rather than being limited by the size of fd_set), and than
    it can detect a few more different kinds of events. I find it a little
    hard to believe that one or the other would "not fit your software's
    structure," and suspect that you may not have a correct understanding of
    things.





  11. Re: timeout problem while using poll()

    vippstar@gmail.com writes:
    >On Nov 8, 5:15 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
    >> Rick Jones writes:
    >> >Sinan wrote:

    >
    >
    >
    >> >> if(sendcmd) {
    >> >> if(sendcmd()) {
    >> >> sendcmd = NULL;

    >
    >>
    >> >Um, why the two "sendcmd()" calls there?

    >>
    >> There isn't. He's using a stupid C trick of treating a function pointer as
    >> a boolean.

    >
    >What do you mean with "C trick"? It's well defined.


    It may compile and execute correctly, but it obviously impairs
    readability, as per this particular thread.

    scott

  12. Re: timeout problem while using poll()

    On Nov 8, 9:55 pm, sc...@slp53.sl.home (Scott Lurndal) wrote:
    > vipps...@gmail.com writes:
    > >On Nov 8, 5:15 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
    > >> Rick Jones writes:
    > >> >Sinan wrote:

    >
    > >

    >
    > >> >> if(sendcmd) {
    > >> >> if(sendcmd()) {
    > >> >> sendcmd = NULL;

    >
    > >> >Um, why the two "sendcmd()" calls there?

    >
    > >> There isn't. He's using a stupid C trick of treating a function pointer as
    > >> a boolean.

    >
    > >What do you mean with "C trick"? It's well defined.

    >
    > It may compile and execute correctly, but it obviously impairs
    > readability, as per this particular thread.


    That's an acceptable definition for 'C trick' for this context.
    However, I find both methods equally readable. There's always 'that
    other opinion' when it boils down to them. (ie coding style)


  13. Re: timeout problem while using poll()

    On Nov 8, 9:07 pm, Nate Eldredge wrote:
    > Sinan writes:
    > > what i'm doing is i have a udp socket descriptor, i set POLLOUT and
    > > POLLIN to use same socket descriptor both sending and reading,
    > > according arguments given to software, i'm sending and/or listening,
    > > when message recieved, i process the content and send reply, and there
    > > is many clients that are sending messages to me simultaneously, i am
    > > not using select because it does not fit to my software's structure
    > > and i do not modify the code over beginning. by saying kernel does not
    > > modify timeout value is, i guessed or expected something like happens
    > > while using select(), select modifies timeval structure, that is what
    > > i was expected. it seems i need to re-think about my code's structure.
    > > Thanks for replies.

    >
    > This is kind of hard to understand. It would be a lot easier if you
    > could use complete sentences, capitalization, and reread your article
    > before posting, to see if it makes sense when read by someone who isn't
    > familiar with what you're doing.
    >
    > Anyway: it's fine to read and write on the same socket. But these are
    > independent operations. You seem to be under the impression that
    > POLLOUT has to be set whenever the socket is being used for output at
    > all. That's not correct. You set POLLIN if you want to wait until the
    > socket has data to read (or until the timeout expires). You set POLLOUT
    > if you want to wait until the system is able to send your data, but
    > normally it's always able to send, so there's no wait needed and poll()
    > would return at once. You're perfectly free to send() data without
    > calling poll() with POLLOUT first. AFAIK, there is a chance that send()
    > could block, but with UDP this would occur infrequently and probably
    > only for a very short time.
    >
    > So the simplest way to do what you want would be something like:
    >
    > - poll with POLLIN
    > - upon return, some data is ready to read (or it timed out)
    > - read the data with recv()
    > - send the response using send(). No need to poll here.
    > - repeat.
    >
    > select() would work just as well here, by the way. The main advantage
    > of poll() over select() is that it can poll an arbitrary number of file
    > descriptors (rather than being limited by the size of fd_set), and than
    > it can detect a few more different kinds of events. I find it a little
    > hard to believe that one or the other would "not fit your software's
    > structure," and suspect that you may not have a correct understanding of
    > things.


    I have just removed POLLOUT, did some modification and it is running
    perfectly. I understand timeout behavior now better.
    Thanks for replies.

  14. Re: timeout problem while using poll()

    On Nov 8, 9:22*am, Sinan wrote:

    > what i'm doing is i have a udp socket descriptor, i set POLLOUT and
    > POLLIN to use same socket descriptor both sending and reading,
    > according arguments given to software, i'm sending and/or listening,
    > when message recieved, i process the content and send reply, and there
    > is many clients that are sending messages to me simultaneously, i am
    > not using select because it does not fit to my software's structure
    > and i do not modify the code over beginning. by saying kernel does not
    > modify timeout value is, i guessed or expected something like happens
    > while using select(), select modifies timeval structure, that is what
    > i was expected. it seems i need to re-think about my code's structure.
    > Thanks for replies.


    You still are making no sense. Since your call to 'poll' will never
    block, since a write on a UDP socket is always possible immediately,
    the timeout wouldn't be modified even if you used 'select'. The call
    didn't block at all anyway.

    DS

  15. Re: timeout problem while using poll()

    David Schwartz wrote:
    > You still are making no sense. Since your call to 'poll' will never
    > block, since a write on a UDP socket is always possible immediately,


    Unless the stack happens to have intra-stack flow control and the
    transmit queue(s) of the outbound NIC are full. Linux and IIRC both
    have intra-stack flow control for UDP. Anywhere one can run a netperf
    UDP_STREAM test and have the sending side have plenty of left-over CPU
    and show a "send" rate equal to link-rate there is intra-stack flow
    control.

    > the timeout wouldn't be modified even if you used 'select'. The call
    > didn't block at all anyway.


    There are or at least were some stacks where the timeout parameter was
    value-result (IIRC that is the correct term) and would be updated on
    exit from the system call to reflect how much of the callers original
    timeout remained.

    rick jones
    --
    web2.0 n, the dot.com reunion tour...
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  16. Re: timeout problem while using poll()

    Rick Jones wrote:
    > David Schwartz wrote:
    > > You still are making no sense. Since your call to 'poll' will never
    > > block, since a write on a UDP socket is always possible immediately,


    > Unless the stack happens to have intra-stack flow control and the
    > transmit queue(s) of the outbound NIC are full. Linux and IIRC both


    In my mind I thought I'd typed "Solaris" but clearly Solaris went poof
    somewhere between my brain and my fingers

    rick jones
    --
    oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread