On Tuesday, January 7, 2014 3:12:43 PM UTC+5:30, Saúl Ibarra Corretgé wrote:
>
>
> > 
> > Yes, on_read is the read callback passed to uv_read_start and 
> > after_work_cb is passed to uv_queue_work. 
> > on_keystroke is callback passed to uv_read again but for tty stream. 
> > 
>
> I see. 
>
> > Sorry I do not have libuv only code at the moment, but it is simple tcp 
> > server on Windows. 
> > It reads input data (predefined size) from socket and to process that 
> > data it fires fixed number of threads using uv_queue_work. 
> > 
>
> uv_queue_work is an opaque thread pool, what do you mean by "fixed 
> number of threads"? On Windows it uses QueueUserWorkItem 
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms684957(v=vs.85).aspx
>  
> so I guess it could take a while to execute if you saturate it. But I'm 
> just guessing here. 
>
> Side question: why do you process the data in a different thread? What 
> kind of processing are you doing? 
>
> > Now when I connect to this server using simulator (which simulates 
> > thousand connections) and send loads of *asynchronous* data to server, 
> > sometimes only on_read gets fired continuously for long time despite 
> > worker threads are done with processing for quite a time back, 
> > I do not get after_work_cb for any of them, neither do I get tty 
> > callback even after keyboard input. 
> > 
>
> As for not getting the TTY callbacks, I don't really know why, sorry. 
>
>
> Regards, 
>
> -- 
> Sa�l Ibarra Corretg� 
> http://bettercallsaghul.com 
>


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).

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.

Tnx,

Ashish


-- 
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