On Thu, 2009-04-23 at 23:29 +0200, Giuseppe Scrivano wrote: > Hi, > > Actually it is used there to don't suffer I/O bound operations in the > scheduler, at least in the part that can be executed only by a thread at > a time.
But how this can happen? When scheduler calls addReadyConnection there is always data pending to be read on that socket. Anyway, we also have a recv call with time out. > Which advantages will we have to move it away from there? When I proposed to move it from there I was thinking at 2 issues: 1. notifications - I'm not sure how to handle them: centralized per socket or per stream ID. If we'll handle notifications per stream ID there is no need to move recv call from ClientsThread. 2. incomplete messages I may receive incomplete messages. How to tell if on the next read I'll have a message for this stream ID or for another that needs to be handled by another ClientsThread. Andu. > > Giuseppe > > > Alexandru IANCU <alexandru.ia...@gmail.com> writes: > > > I would remove recv call from ClientsThread. ClientsThread read from a > > buffer and write to a socket(sockets write only to ClientsThread). This > > pair should be provided by scheduler. > > > > Andu.