Re: CRT fd limitation in Squid NT port

Hello Serassio,

Tuesday, July 5, 2005, 23:55:38, Serassio Guido wrote:

> I agree: MS CRT is too limited and the impact in the source code
> should be minimal.

>>Say, add one or two headers
>> and a .cc file. From that, here is an idea:
>>
>> We could implement a class, say, FileDescriptor. Then we derive FDfile,
>> FDtcp, FDpipe & FDudp from it (or whatever fd kind is needed).
>> FileDescriptor class should have pure virtual methods for write,
>> read, open, connect etc. Then we have functions like
>>
>>__inline int
>>write(FileDescriptor& fd, const void *buffer, unsigned int count) {
>> return fd.write(buffer, count);
>>}
>>
>>int FDtcp::write(const void *buffer, unsigned int count)
>>{
>> return ::send(fh /* member of FileDescriptor */,
>> buffer, count, 0);
>>}
>>
>>int FDfile::write(const void *buffer, unsigned int count)
>>{
>> DWORD cbWritten;
>>
>> if ( WriteFile(fh, buffer, count, &cbWritten, NULL ) {
>> return cbWritten;
>> } else {
>> ...
>> }
>>}
>>
>> This way, the source tree would remain mostly unchanged and squid
>> won't have that 2048 fd limitation.

> I think that changes should be deeper: My opinion is that we should
> remove any direct reference to FD concept creating a virtualized
> interface between Squid and the OS.
> And this isn't a so simple thing to do ... :-(

Well, that's what the whole idea is about. FileDescriptor class whould
save HANDLE value internally in fh member (see above examples). On the
other hand, existing calls to write/read in squid code won't e broken.

Looks like I didn't catch your way of thinking about virtualized
interface between Squid and the OS. By the way, do you concern only NT
port or HEAD?

-- 
Best regards,
 Andrey Shorin