Re: A controversial topic
- Posted by jimcbrown (admin) Feb 21, 2023
- 1226 views
I was on one of the slowest internet lines in the usa at the time, everything timed out. Lag times of 10 minutes was not uncommon on irc. Setting a 2 minute timeout on http was reasonable.
Agreed - sounds quite reasonable to me as well, given the circumstances.
Wget.exe's resume function was useful every day here in the olden daze.
One of my favorite weather sites updated radar images every 15 minutes, sometimes it took longer than 15 minutes to get a 120kbyte gif. I took to passing 20 second timeouts to wget (which i had wrapped in OE, called via system()), because it was faster to kill the whole process at my end and restart, than wait to see if i was still online with normal timeouts.
Makes sense. Use the tools that work.
I took to running a PHP httpfetch script on my web host, to cut news sites' pages down to 20kbytes, because maybe i could get that without timing out.
Kat
Yep, see above.
I wrote a http fetcher and a daemon in mIRC, from scratch, and the server was threaded.
Considering that it was threaded, such a solution - reimplemented in Eu - would work today for Phix (which has threads). But sadly, still not so much for OE (which lacks them, unless you are okay with nix + fork as a sort of poor man's version).
Also, tasks are a form of cooperative multitasking, but the sockets library didn't play nicely with that - if receive() waited too long before timing out, there was no way for other tasks to continue in the meantime. That would have required preemptive multitasking - or threads.
Or, not reading the recieve queue until there was data in it.
Agreed. We support nonblocking I/O with sockets iirc, so we should be able to do that - though to avoid busy waiting we'd still need a reasonable pause between checks (as I don't believe we support true async, where we'd receive a signal that data was ready). So we'd still need task_yield() (or on a translated shared lib on nix, a call to fork).
So it hurt personally when such things were refused by OE.
I think my point here is that such things generally were not refused - for example, the improved http.e with task_yield() that was done by you was accepted into OE by the OG dev team.
(Then, yes, we were forced to put in a less than satisfying workaround for the translated shared library case - because the tasks implementation was heck to work with when dealing with being inside of a translated shared library. Requiring lots of C knowledge and much volunteer time and effort. If someone had given us a patch to just fix it and make it work, it definitely would have gone in.)
