client_http_run_once example: use NEAT_RUN_ONCE #147
Conversation
This example extracts the backend fd and runs its own IO loop and invokes neat_start_event_loop(ctx, NEAT_RUN_ONCE) for every action on the backend fd.
|
I'd normally take on an issue like this, however, I'm currently busy on another part of the project. I might be able to look at this next month, depending on circumstances, unless someone else has a look at this. I glanced quickly over the code, and I think your approach should work, ideally. I don't find the fact that it doesn't work surprising, since it's a use case that hasn't really been looked into yet. Libuv does have an example program where an event loop is embedded inside another. I don't have the link at hand, but if you find it, you could give it a spin and check if that example works, just to rule out the possibility that libuv doesn't support it on your system. |
|
Thanks, that was useful input anyway and I'll proceed and write up a more raw libuv using snippet and see if that works for me before digging deeper into this. I'll be back when I have more. |
|
This probably doesn't test the exact same flow, but I wrote up a test code that uses libuv directly and I extract only the backend file descriptor to know when to act and it downloads my 512MB test file from a localhost web server just fine: https://gist.github.com/bagder/ffb613e3c3c5f41813b31fc09ef1c261 |
|
I just played a bit with the code from your PR:
This might not be a helpful contribution to the issue but maybe it helps... |
|
Thanks! Oh right, it definitely needs to call for the timeout case as well. Interesting that it needs This will take me further! |
|
When I invoke However, when I try requesting a page from for example And it shows that for an app like this, exporting a "maximum time to wait" timeout value in the API would be useful. |
... makes the example work, albeit a bit slow.
|
How about this:
Works for me and this specific example - might be the wrong strategy in a bigger picture. |
|
You on Linux too? Because that does not work for me! If I make the change "on timeout do nothing", my test just stops doing anything after 1.2 milliseconds and then loops around timeouts. The other two changes don't have any effect for my test case. Puzzling! In my case, my target host name returns AAAA entries from DNS but IPv6 doesn't work but I can't think of much other things that are out of the ordinary. |
|
output from the example when tested against |
|
OSX, on Linux the behavior is exactly how you mentioned... mh... |
|
The When I increase the timeout and add some more instrumental printf() debugging, it is obvious that we don't get the epoll backend fd to trigger action when there's incoming UDP responses for the name resolves. Only once we call neat again after a time-out, the loop runs and then it handles the received DNS responses. With a 5000 ms timeout I can see this: I have yet to figure out why this is so. I added the And then it goes on a little further and returns out from the loop again only to not trigger on anything further and it'll sit through another time-out: ... and from hereon everything looks sensible. |
|
this example is now broken due to API updates, see also #162 |
|
After I fix the |
|
Takes two seconds for me. |
|
On Linux? And I should clarify that it takes 15 seconds with 5 seconds poll waits, which means that it times out three times. if we lower the timeout it'll of course run faster. (I'm on Linux kernel 4.5.4 without IPv6 working). Two seconds sounds like it triggered at least two timeouts for you as well? |
|
The new Happy Eyeballs code is timeout-based (currently 10ms between each connection attempt), so if you specify excessive timeouts it is certainly going to slow things down. I would assume this is where |
|
Give this a try: 80cef52 |
|
That's helpful! It removed all but one longer wait. With added debug output that tells when it has exited poll due to timeout and how long the timeout was, it starts out like this: |
|
The longer timeout is a timeout in the DNS resolver code, which is as intended at this point. You may ignore that for now. |
|
Note that any timeout value in the DNS resolver has been chosen by random and can be changed at will. |
|
This PR has been dormant for quite some time now. What is the current status?
|
|
I really need to use the |
This example extracts the backend fd and runs its own IO loop and
invokes neat_start_event_loop(ctx, NEAT_RUN_ONCE) for every action on
the backend fd.
NOTE this example doesn't seem to work and I would like someone to throw an eye on the example to see if the API is used wrongly and if so help me fix the example, or if the API is used correctly take a look at the NEAT code to see why it doesn't work!
This example is mostly a copy and paste from the
client_http_getexample and is supposed to be used with the exact same command line arguments.