Patch - correct support of select/accept method

Hello All,

I send this message once more because I think previous
one was lost in other thread.

Problem:
========

I want to wait for more then one event - not
to be blocked on FCGX_Accept_r(), for example
timeout, other sockets, etc.

Proposed solution (in many places in this list)
-----------------------------------------------

Call select(2) on the socked opened by FCGX_OpenSocket
and when input event occurs, call FCGX_Accept_r.

The problem is that if server disconnects or do not
send the data - calls connect(2) and not calls
write immideatly, then FCGX_Accept_r will try to call
accept(2) once more, and thus will be blocked until
next new connection.

Thus method of select followed by FCGX_Accept_r
may not work.

Real Solution (Patch)
=====================
I had written a patch that introduces two new API
functions:

FCGX_Accept_Only_r()
FCGX_Continue_r()

The first one makes single accept call only, thus
it will not block on file descriptor if it has.

FCGX_Continue_r continues the job after accept.

Several comments:
=================

1. OS_Accept on UNIX checks if there is actual data
   on a socket using select and otherwise try
   to connect once more. It was workaround
   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 actual
   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? Is there
   a possibility that it will be accepted?

Thanks,
   Artyom

accept_patch.patch.gz
Description: pat732283168

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