On 11/17/2010 04:34 PM, Amos Jeffries wrote:
On Wed, 17 Nov 2010 16:20:02 -0700, Alex Rousskov
<[email protected]> wrote:
On 11/17/2010 04:12 PM, Amos Jeffries wrote:
* creates namespace Comm::IO for the read and write functionality to
exist.
Do we really need the Io sub-namespace? What Comm[unication] namespace
parts are not about I/O? For example, all code already in src/comm/,
and
pretty much everything in comm.cc is also about I/O. If you are not
sure, let's drop the Io namespace from Comm.
For the record comm.cc currently handles read IO, write IO, FD
management, event queues, socket opening, delay pool queueing,
destination
DNS resolving. It is slightly unclear how much of that will remain in
comm
layer and how much will be pushed out into better scopes.
In your list, only the DNS resolution seems out of Comm scope to me.
I'm thinking also the FD stuff is a separate scope lower than comm, which
the rest of the code goes through comm to get to. I may be fully wrong and
it turns out to be just an fde class scope.
Yes, it is possible that FD stuff should be isolated, but if one has to
use Comm and only Comm to use FD++, then perhaps there is no need for
that lower layer.
The read delay pools stuff can probably be split a bit like the new client
write pools. Data queued in higher scopes with comm doing only the low
level switching and IO parts.
We are getting far out of scope here, but I think the client write pools
are pretty tightly integrated with Comm. I actually tried to isolate
them at first, but found that it would make things worse: The Comm
caller does not care how [fast] Comm writes something. It keeps the
caller simple.
Also, small bandwidth limits need tight integration with Comm for
performance reasons -- it costs a lot of CPU cycles to notify somebody
far away that a few more bytes were written, just to hear an "oh, fine,
keep going" response.
Where to keep general pools configuration is a separate question. It is
not clear whether client_db belongs to Comm.
Cheers,
Alex.
