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 ShorinReceived 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