Re: [Speedycgi-users] FIXED!!!

[Sam H. <sa...@da...>]

When the backend is forked it keeps a copy of fd-2 from the frontend
(a direct copy of that fd, not a socket), and then if that's duped, the
backend can hold it open, even if the frontend exits.  It's probably a
pipe into the web-server, and the web-server is waiting for EOF on that
fd before considering the cgi done.  Since the backend is still running
and still hanging onto the other end of that pipe, it just hangs.

The reason the backend is given a direct copy of fd-2 is so that perl
compile errors will show up on stderr.

Maybe we could turn fd-2 into a pipe that is closed when the first frontend
exits.  That would fix the hang, but later runs of the perl code wouldn't
be able to write on that duped stderr file.



 > I found the problem - it was Parse::RecDescent (which is included by
 > Spreadsheet::WriteExcel).  Parse::RecDescent is dup-ing STDERR on _MODULE
 > LOAD_, which is screwing something up in speedy.  Adding the following
 > code to the beginning of my program fixed the problem.
 > 
 > BEGIN {
 > 	close(STDERR);
 > }
 > 
 > This prevented Parse::RecDescent from dup-ing a valid file descriptor, but
 > also screws up error reporting.  Is this a feature or a bug with speedy?
 > 
 > Alternatively, to keep STDERR, I might dup it, close it, load
 > Parse::RecDescent, dup it back, and then reclose the dup-d one.
 > 
 > Any ideas from users?
 > 
 > Jon
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.NET email is sponsored by: Geek Gift Procrastinating?
 > Get the perfect geek gift now!  Before the Holidays pass you by.
 > T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users