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
CGI_Fast.pm-patch

History Show all quoted text
  Tue Oct 12 17:04:54 2004 Guest - Ticket created
Subject: CGI::Fast bugfix
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.

  Thu Apr 16 23:14:33 2009 MARKSTOS [...] cpan.org - Correspondence added
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. >
  Thu Apr 16 23:14:33 2009 The RT System itself - Status changed from 'new' to 'open'
  Sun Jul 19 21:12:43 2009 MARKSTOS [...] cpan.org - Correspondence added
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.
  Sun Jul 19 21:12:46 2009 MARKSTOS [...] cpan.org - Status changed from 'open' to 'rejected'
  Fri May 23 14:28:14 2014 The RT System itself - Queue changed from CGI.pm to CGI