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.
