Re: Waiting on more then one event -- Accept_r

Hello,

After looking carefully to the code, I had found that
an approach of select/FCGX_Accept_r() 
is only half way correct, because
if something fails in FCGX_Accept_r() it will try
to connect once more, and will be blocked.

Thus select/FCGX_Accept_r may not work well at all.

Thus I had written a patch that introduces two
new API functions:

FCGX_Accept_Only_r()
FCGX_Continue_r()

The first one only makes accept call, thus
it will not block after select to fd.

FCGX_Continue_r continues the job.

Several comments:

1. OS_Accept on UNIX checks if there is actuall data
   on a socket using select and otherwise tryes
   to connect once more. It was work around
   for Linux 2.0.x and SCO Unixware for a
   connection that was dropped after and
   an accept call and before first read
   that may caused read block forever.
   Thus select was called in order to
   insure that read not blocks. This may
   reduce performance (waiting for actuall
   data after connect) and cause wrong behavior:
   accept called twice and thus block the thread.

   I had added a function OS_Accept_NoSelect
   that workarounds this problem for 
   use with OS_Accept_Only. For os_win32 it
   is just same function OS_Accept.

2. I didn't write comments in Full FCGI style
   if the patch accepted I can do this.

3. The code has really good comments and
   quality - it is just pleasure to work with it.

4. Is there any problems with this patch?

Thanks,
   Artyom

accept_patch.patch.gz
Description: 2110222781-accept_patch.patch.gz

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/