Programming

Below is my code. Every once in a while the select call takes as long as 150 seconds (discovered by printing time before and after this statement) while the timeout specified into it is only 1 second. Any clue why? I can't believe that select call which has been around for centuries can have a bug, but I don't see what I'm doing wrong.

Code:

 
    fd_set fdread;
    fd_set fdwrite;
    fd_set fdexcep;
    int maxfd;
    FD_ZERO(&fdread);
    FD_ZERO(&fdwrite);
    FD_ZERO(&fdexcep);
    /* set a suitable timeout to play around with */
    timeout.tv_sec = 1;
    timeout.tv_usec = 0;
    /* get file descriptors from the transfers */
    curl_multi_fdset(cmh, &fdread, &fdwrite, &fdexcep, &maxfd);   
    int ret = select(maxfd+1, &fdread, &fdwrite, &fdexcep, &timeout);

Is your timeout value a struct timeval or a struct timespec? select uses struct timeout, pselect uses struct timespec.

Neither. It is struct timeval.

Hmm. That's the correct structure.. but select() has odd side-effects. It modifies the timeval you give it, to reflect how much time was left. You have to update it every time to get the same timeout!

Yes, I'm updating the timeout value everytime.

How do you know the select() is actually taking that long? Maybe your process is getting swapped out? As you said, select() isn't exactly untested code.

Also, if you're running on Solaris, and your file descriptor set is large and not constant, read the man page for "poll.7d". It scales much better, only returns active fds so you don't have to iterate through every fd every time to see if it's active, and you don't have to rebuild the entire list of fds every time - you just add and delete fds to a set that the kernel tracks.

There is clearly something else in your code/system that is not shown. select() was and is actively used as a very reliable way to implement sleep(), usleep() and other "sleep" calls on old systems that do not support them. Almost categorically select() is not directly causing your problem - if what you posted is correct.

If your process has low priority or is running as a normal process on a realtime system you may get extended waits. Not 120 seconds.

If you are doing writes on the fd select is waiting on even with huge (multi-GB) data elements I would still find 120 seconds hard to believe. It looks like you are calling curl - so it is probably a linux box right?

We need: OS version, kernel version, and what type of system you have - realtime, desktop, etc.

Have you traced your code and watched it wait in select() 120 seconds, for example?

---------- Post updated 03-31-10 at 06:17 ---------- Previous update was 03-30-10 at 20:27 ----------

Q:
int maxfd=some_fixed_value (?)

where is int maxfd initialized?