-
Notifications
You must be signed in to change notification settings - Fork 500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use select() syscall to avoid busy waiting #110
Conversation
Hmm, interesting. Can you explain exactly what this does please? :) |
Well, busy-waiting is a technique in which a process repeatedly checks to see if a condition is true. In this case, the condition is "has any of the requests been answered?". This is in general a wasteful practice, so the OSes provide an array of system calls to avoid it. For example, to wait 10 seconds you won't do: $before = time();
while ($before+10 > time()); But instead: sleep(10); For this case, select() is a traditional solution, and cURL provides a wrapper through curl_multi_select(). It just blocks until one or more of the requests has I/O available, and you can set a timeout (1 second by default). |
Right, I understand how Thanks for this! I'll check it out and merge. |
@rmccue any progress on this topic? |
Sorry, I've been pretty busy and didn't get around to trying this out yet. Will do. |
ping @rmccue |
Maybe we should add some checks as in http://stackoverflow.com/a/15173929 |
This may be the same as WordPress#110 This will require more testing across various libcurl versions. I doubt that the timeout is necessary for curl_multi_select (calls select() if it can), but leaving in one just in case of bugs, so that it will end. - Haven't thoroughly checked for relevant libcurl bugs. Asynchronously wait for events with a short timeout if CURLM_CALL_MULTI_PERFORM fails.
I have a branch which independently has the exact same approach (to the exact same problem) in a slightly different location. See #284
We probably want to usleep() in the rare case (OS/PHP/curl setup?) that curl_multi_select returns -1, but this is something I'm in favor of. |
This PR was closed inadvertently when we changed the stable branch from |
PR recreated as #493 |
Currently it consumes a lot of CPU, it's a no-brainer i think.