Hi,


Hi Saúl,

Thanks really for your looking into this.

If we call uv_queue_work unconditionally it goes on creating thousands
of threads (I did see it through Windows task manager). It was becoming
tough to manage resources in that case. To avoid that, I call
uv_work_queue only for predefined number of times, and next call(s) will
occur only after I got callback(s) to previous call(s).


I see.

My event loop puts incoming data (requests) in a queue and routine
passed to uv_work_queue (thread) processes those requests in queue
sequentially. Thus, event loops job is only to dump incoming requests to
queue through on_read callback, and to attend other callbacks
(after_work_cb, tty callback etc)

Currently it is simple echo server. So nothing much I am doing in
threads except copy the request (for sake of doing something), so that
after_work_cb can send it back to client.

It all works fine. But when I simulate thousands of connections those
bombards my server with continuous asynchronous requests, event loop
keeps invoking only on_read callback. Thus, after_work_cb never gets
called and my request queue goes on increasing forever to system memory
limits. (TTY callback also never gets called but I guess underlying
reason might be the same for both)

What I observed additionally is, once I stop simulator, event loop
immediately resumes calling back these other callback.


Since what you are implementing is an echo server, thus i/o bound, lets try to create a simpler test case: don't use uv_queue_work at all. Just do the uv_write on the read callback to send the reply back.

Then hammer your server with those thousands of connections and lets see how that goes.


Regards,

--
Saúl Ibarra Corretgé
bettercallsaghul.com

--
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/groups/opt_out.

Reply via email to