Re: Introduction

On Sat, 30 Apr 2005 10:46:37 +0200
  Serassio Guido <guido.serassio@acmeconsulting.it> wrote:
>>You make me laugh. squid2.5 use read/write/send/recv/ etc. as
>>well as FD_READ_METHOD/FD_WRITE_METHOD.
>>It seems the same things are in squid3.
>>With classes we have only read/write/open/close to any handle and
>>can control it in single place.
>>Why you don't see "bytes_read += rc;" that is fd_bytes() and that
>>is one more function call etc. ?
>
> Please, stop here :-)
>
> I don't wrote that your solution is wrong, or that C++ classes are
>bad. I wrote that your solution is slower.
>
> I have removed similar things some time ago from the Windows port
>for poor performance reasons.
I don't understand this. Really call to read/write/sevd/recv is call
to a number of system's API calls and one more call get 0.0001%
 performance

>
> On both Windows and OS/2 we have the problem that File handles and
>Socket handles are not equivalent for I/O function calls, when Squid
>code use generic file descriptor for both types.
>FD_READ_METHOD/FD_WRITE_METHOD is a simple and efficient method to
>solve this problem, probably not the better.
>
> On Windows there is another problem, I don't know if this is true on
>OS/2 too:
The same for OS/2 too..

> Sockets handles returned from socket() and accept() are not mapped
>in the MS C runtime internal file descriptor table, so it should not
>possible to use a fd_table like Squid does, because value of returned
>disk FD and socket handles are not related. With some tricks this
>problem was avoided, but this workaround is the cause of the current
>2048 FD limit in the Windows port. There is another side effect: any
>socket function call on Windows must be encapsulated to do a
>translation from C Runtime FD to Win32 socket handle.
>
>For the first problem a good C++ solution could be to have something
>like a FileDescriptor class, with create(), read(), write(), close(),
>etc SPECIALIZED action in place of READ_HANDLER/WRITE_HANDLER, that
>we call as fd.read(), fd.write(), etc. This is very close to your
>fde::read() approach, but without any decision in the code.
>
> But this is not enough, because don't solve the second problem. Here
>the solution could be the usage of something like a Squid_Socket
>class with all socket calls encapsulation.

I am not quite understand problem
I have made:
class squid_fde wich is analog to filedescriptor
and
class squid_fdeArray
{...
   squid_fde *fd_table;
....
extern squid_fdeArray squid_fd_table;
with typical usage as squid_fd_table.fd_table[fd] instead of
fd_table[fd]

usage of squid_fd_table class may be not very efficient, but very
convenient so that it is single place for all filedescriptor's
operetion. It is possible to have variable number of fds etc.

In os/2 there is two limits on socket's number: first is 2048 with so
called 16-bit old TCP/IP stack and default 8K with 32-bit TCP/IP
stack. But with 32-bit stack there is one more problem: select,
macroses FD_XXX, fd_set structure and
#pragma pack(4)
typedef struct fd_set {
         u_short fd_count; /* how many are SET? */
         int fd_array[FD_SETSIZE]; /* an array of SOCKETs */
} fd_set;
#pragma pack()
and it's usage in comm_select.c(pp)

Nevertheless this it seems solved

SY,
Evgeny Kotsuba
Received on Sat Apr 30 2005 - 05:06:01 MDT