Re: [PATCH] Comm Write cleanups

On 11/17/2010 04:34 PM, Amos Jeffries wrote:
> On Wed, 17 Nov 2010 16:20:02 -0700, Alex Rousskov
> <rousskov_at_measurement-factory.com> 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.
Received on Wed Nov 17 2010 - 23:47:47 MST