durusmail: quixote-users: scgi and __del__ cleanup in publisher
scgi and __del__ cleanup in publisher
2004-03-26
2004-03-27
2004-03-29
scgi and __del__ cleanup in publisher
Evan LaForge
2004-03-27
Not having MySQLdb in front of me, I don't know what it's doing, but it looks
like Cursor has a connection or something it wants to call close() on except
that the connection was deleted first.  __del__ methods should not rely on
the world being in a sane state when they're called.

I agree with you that it's better to explicitly close things rather than rely
on a __del__ method.

>             try:
>                 os.write(self.parent_fd, "1") # indicates that child is =
> ready
>                 fd =3D passfd.recvfd(self.parent_fd)
>             except (IOError, OSError):
>                 # parent probably exited  (EPIPE comes thru as OSError
>                 self.shutdown()
>                 raise SystemExit

You could make sure shutdown() would be called no matter what by overriding
SCGIHandler.serve with

try: QuixoteHandler.serve(self) # assuming your superclass is QuixoteHandler
finally: self.shutdown()

Presumably you're already subclassing WhateverHandler for your app.

It looks like whoever wrote the recipe meant to do what you did, since they
called a non-existant publisher.cleanup() in the medusa example.

If just anyone can edit the wiki, you could fix the recipe (and change the
try...except on the medusa example to try...finally while you're at it) to
shutdown (or cleanup) explicitly, but the SCGIHandler override is generally
useful even if you're not ReusingConnections.  The Publisher has no way to
know when its process is quitting, so it needs to be told by whoever is
managing the process.


reply