On 02 August 2002, Robin W?hler said:
> I tried running Quixote on a low-end machine (486/100, 40MB, OpenBSD 3.0)
> which basically forks fine, except for these two issues:

Just going through my email backlog and I realized no one ever responded
to this.  Oops.

> 1) /dev/urandom seems awfully slow (like 4 seconds to get 8 random bytes).
> This is not a Quixote problem, but perhaps randlong() might become
> a method of the SessionManager class so it's easier/cleaner to override.

OK, I think I see a way to do this.  Did you ever figure out why
/dev/urandom was so slow for you, though?  I mean, 100 MHz 486 is hardly
state-of-the-art, but it's not *that* slow!

> 2) No signal handling in fcgi.py. The problem - on OpenBSD (Linux/Solaris
> don't show this behaviour) - seems to be this: If FastCGI terminates a
> process (by SIGTERM) it might interrupt a call to accept(). If this
> happens and the signal is not being handled by the process, subsequent
> accept()s on the same socket (by a new process) will block forever. The
> signal handler does not even have to do anything, it just needs to be
> there...

Weird.  Is that OpenBSD's documented behaviour, or a bug?

> I have pasted a minimal patch below. This is yet incomplete, it works fine
> but the terminated app generates an exception (stderr of FCGI instance
> not initialized).  Should sys.exit() work from inside a signal handler?
> That didn's work when I tried it...
[...]
> --- orig/fcgi.py        Wed May 29 02:36:51 2002
> +++ fcgi.py     Thu Jul 11 11:44:48 2002
> @@ -37,6 +37,15 @@
>  from    cStringIO   import StringIO
>  import  cgi
>
> +
> +
> +def _term_handler(signum, frame):
> +    pass
> +
> +import signal
> +signal.signal(signal.SIGTERM, _term_handler)
> +
> +

Signal handling raises all sorts of red flags with me, mainly because
people much smarter than me stay away from it, and I don't really
understand their reservations.  Your patch looks about as safe as a
signal handler can, though.  BTW, did you try os._exit() rather than
sys.exit()?  sys.exit() involves raising a Python exception, which
undoubtedly involves allocating memory, which is a no-no for signal
handlers (malloc() is not reentrant on some systems).  os._exit() is a
much shorter path to the real exit() system call.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org