Re: Patch - correct support of select/accept method

Thanks for the patch.  I'll have a look at this soon.

Rob 

> -----Original Message-----
> From: fastcgi-developers-bounces+robs=chelsea.net-VYFNfGabXYtBDgjK7y7TUQ@public.gmane.org
> [mailto:fastcgi-developers-bounces+robs=chelsea.net-VYFNfGabXYtBDgjK7y7TUQ@public.gmane.org] On Behalf
> Of Artyom
> Sent: Monday, November 12, 2007 4:43 AM
> To: [email protected]
> Subject: [FASTCGI] 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


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