-
Notifications
You must be signed in to change notification settings - Fork 19
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
PhpClient should be wrapped in workers #48
Comments
I am not sure if this really works. Because php doesn't support threads at all. (even pthread is not really what we needed, because it doesn't share references) |
Threads are not a requirement though. The runloop could still make progress two downloads in parallel, so long as each of them is performed bit by bit. |
Did I miss something? I thought the http request a sync operation. How does that parallelize? |
Well, in theory the pipes drive the sources which each read a (possibly empty) slice through a worker which hands control back to the runloop, which then schedules the next worker to progress. The IO occurs in parallel anyway (since the kernel with its TCP stack and also the server on the other end progress independently). The trick is not to block until all data is read, but just read it bit by bit. And ideally not to block if no data exists, but just yield |
Oh that means need to find out the "bit by bit" api in php. But I have no idea atm. Or maybe just replace |
I created a non-blocking tink_tcp connection for php based on stream_select which might make it easier to accomplish this if read bit by bit. But it also created a mess in the source hence my comment haxetink/tink_tcp#5 |
I just realized that I have forgotten that bit.
The text was updated successfully, but these errors were encountered: