This isn't exactly the case, usually the events are happening in FIFO order to prevent such kinds of obvious starvation. Anyway, it is hard to say anything without seeing an actual test case. Looking forward to play with it!
On Wed, Mar 26, 2014 at 10:59 AM, Ashish <[email protected]> wrote: > > > On Wednesday, March 26, 2014 1:28:13 AM UTC+5:30, Saúl Ibarra Corretgé > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> To process incoming requests I fire few DB queries and finally I >> >> send back response from 'after_thread' callback. Since its time >> >> consuming operation I've I threaded it off. (For some requests, I >> >> also call uv_async_send through thread to send some intermittent >> >> updates to requester client) >> > >> >> If not uv_queue_work what are better options for me, please? >> > >> >> What OS are you in? If you are on Unix you can export the >> UV_THREADPOOL_SIZE environment variable to the number of threads you >> want (it's capped at 128). >> >> Give it a shot and let us know if you see any difference. >> >> - -- >> Saúl Ibarra Corretgé >> bettercallsaghul.com >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> Comment: Using GnuPG with Icedove - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJTMd/VAAoJEEEOVVOum8BZQTMP/1PYUdu6AIEz2pigUn559Ls1 >> aB8iS2RoxhvfWBTeabp1uoaGYF1iitCz7rPsMexvlaCXqThNy+9LdwGBCdcg/w7I >> OnPfZkwn7IRaQf2CoOSdrrBs2vtWLEO9H7jKxM9MzVryNSsjDkCdnVffwObeKNKc >> fHooa8mMPBie+jsmN8dtbXXCI53Lb/pP28lgX257Y4bq0agtRzVgrwMJ9mHbzmBM >> Ctzjk8oxGgBSBA7Yq4cr1djixAScUPUemxpIb1u4qJbP+mM/RfukdVFYsVV4ITa2 >> PY49dw4TphGJSNi3/pnk4kh2Nr3lOPMmhLv0ezkz3ISePiqR5RsXBzxOvEczzLbI >> VJaA71YPqCn4gHJ03lwyAiz+641m2WHWrTX0qtANGvXQdpMQFeHd4c910AKa6mKf >> l1RFhcepX6Zs9RG0zUJ2ZtEmKVHs3Gy9ooFM1gTuKLXLck/7m/5i2h86BT3Ea8hc >> GAPF1JjDCqu/ENSe2IXWUB3IgtF0oq3kbHMauRIjmfsWKe9IP86mV4sF9RqKqqzS >> Hn0a2jqLVh0xLTG04xPRjnQXtzDyc3GKNFlWp1+hxTd6fRIOBPzSEk6Wz0WGwlvx >> P6X70WmZDGB6VvlTMezz/0SAbkUP8T4fZTIqQaiYi9Ym6/QA309AJ6MAG0RZgXP/ >> 8kBkiNrRAGscriAIwBrE >> =idMh >> -----END PGP SIGNATURE----- >> > > > I am on Windows. But it is not about number of threads really. I've > confirmed it and found despite of completion of threads successfully libuv > doesn't call 'after_thread' and any other callbacks when there are loads of > read requests. > > Well, let me try to put it in simple example which doesn't involve any > threads: > Let's say I am calling 'uv_write' from event loop itself ('on_read') and > just echoing back requests to the client. > Now, when there is continuous load of incoming requests, libuv would never > calls 'after_write'. It will call 'after_write' only when incoming requests > are stopped (or paused even for microseconds). > > This could be correct as per event based design. Because for each of > incoming request libuv keeps calling 'on_read'. And since there are > non-stop load of incoming requests, it never find time to call > 'after_write' and other callbacks. > But DoS attackers could exploit this to bring down the server. > > -- > You received this message because you are subscribed to the Google Groups > "libuv" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
