Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 7976
Status: rejected
Priority: 0/
Queue: CGI

People
Owner: Nobody in particular
Requestors: jazzkutya [...] wom.hu
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)

Attachments


Subject: CGI::Fast bugfix
Download (untitled) / with headers
text/plain 834b
This bug is reported in The fastcgi-developers mailinglist archive, but misunderstood: http://fastcgi.com/archives/fastcgi-developers/2003-March/002599.html The symptom: signal received while waiting in CGI::Fast::new (actually FCGI::Accept) is reported only at the next request. It's not related to safe signals. FCGI::Accept() blocks until the next request and does not allow the perl script to handle the signal. That is because Fast.pm does not set FCGI::Request 's flag to 1 (1 is for FCGI_FAIL_ACCEPT_ON_INTR in fcgi) when not used for en external fastcgi application. When used in a normal dynamic or static application it does not even call FCGI::Request (the constructor) and uses the class method FCGI::Accept with flags=0. The attached patch (against version 1.05 of Fast.pm) fixes this by always using an FCGI object.
Download CGI_Fast.pm-patch
application/octet-stream 1.2k

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 1.2k
Thanks for the patch, and sorry there was no reply through the bug tracker for so long. I have just reviewed the 3.43 release to see if this patch has been applied there. It appears it has not. However, if it serious issue, it's surprising no one else has commented on this bug report in the last five years. Do you still believe the patch should be applied? Mark On Tue Oct 12 17:04:54 2004, guest wrote: Show quoted text
> This bug is reported in The fastcgi-developers mailinglist archive, > but misunderstood: > http://fastcgi.com/archives/fastcgi-developers/2003-March/002599.html > > The symptom: > > signal received while waiting in CGI::Fast::new (actually > FCGI::Accept) is reported only at the next request. It's not related > to safe signals. > FCGI::Accept() blocks until the next request and does not allow the > perl script to handle the signal. > That is because Fast.pm does not set FCGI::Request 's flag to 1 (1 is > for FCGI_FAIL_ACCEPT_ON_INTR in fcgi) when not used for en external > fastcgi application. > When used in a normal dynamic or static application it does not even > call FCGI::Request (the constructor) and uses the class method > FCGI::Accept with flags=0. > > The attached patch (against version 1.05 of Fast.pm) fixes this by > always using an FCGI object. >
Download (untitled) / with headers
text/plain 178b
Rejecting due to lack of any "me too" comments in the last 5 years, and lack of follow-up from the original reporter. Please re-open the ticket if you find the bug still exists.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.