Re: [cgi-devel] Issue with request data and threads

[Darren G. <dar...@gm...>]

On 20 August 2010 03:19, Ankur Gupta <ank...@gm...> wrote:

> Thanks for your response Darren.  When the EPIPE happens, the
> request::commit throws an exception which I am catching.  I am creating a
> new request which seems to work fine but closing the old request throws an
> exception.  How does one confirm that the resources allocated for the older
> request did get freed up?
>

You should be able to call request::clear() if the commit() call fails and
then reuse the request.

request::close() actually sends a specific FastCGI packet to the server to
tell it that the request has been dealt with. Would it be less suprising if
you could pass an extra boolean "force" argument to request::close() that
simply ignored errors and cleared the request anyway?

Cheers,
Darren


> On Wed, Aug 18, 2010 at 4:44 PM, Darren Garvey <dar...@gm...>wrote:
>
>> Hi Ankur,
>>
>> On 17 August 2010 21:11, Ankur Gupta <ank...@gm...> wrote:
>>
>>>
>>>  I have encountered another issue.  Here is the description:
>>>
>>>  Thread gets a request, processes it but gets an EPIPE while committing
>>> the response.  The thread could return but instead it continues on to do
>>> another accept.  At this point, the accept fails with an already open
>>> message and the thread exits.
>>>
>>>  How should this case be handled?
>>>
>>
>> This is an interesting issue, one that could be dealt with in a couple of
>> ways.
>>
>> First off, if the response cannot be written back to the server, the error
>> should be raised by the library in the response::send() call. Are you
>> catching this or is no error being raised?
>>
>> I don't see why the library couldn't handle this by accepting a new
>> request when the request is in an error state.
>>
>> Just note that in general you are responsible for closing a request,
>> either by calling commit() or request::close().
>>
>> Thanks for the report.
>>
>> Cheers,
>> Darren
>>
>>
>>
>
>