CRT fd limitation in Squid NT port

From: Andrey Shorin <tolsty@dont-contact.us>
Date: Tue, 5 Jul 2005 23:22:00 +0400

Hello Guido,

  I've been thinking about the problem for a while. Here is what comes
  to mind.

  The only way to leave out CRT fd number limitation is to give up CRT
  use for files and sockets operations. On the other hand, code change
  to the source tree 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 haven't write something in C++ for quite a while. So I'm not sure
  if the idea would work at all ;) May be template thing should be
  used, which I'm not too familar with :) (but will read about it).

  Well, waiting for comments.

-- 
Best regards,
 Andrey Shorin
Received on Tue Jul 05 2005 - 13:22:05 MDT

This archive was generated by hypermail pre-2.1.9 : Mon Aug 01 2005 - 12:00:03 MDT