Ah yes, finally: is a much better approach. Using that gets rid of
any need to modify the scgi source.

I've modified the Wiki cookbook to reflect this approach.

Thanks!

Dave


> -----Original Message-----
> From: Evan LaForge [mailto:quinn@burn.ofb.net]
> Sent: Friday, March 26, 2004 7:56 PM
> To: David Hess
> Cc: quixote-users@mems-exchange.org
> Subject: Re: [Quixote-users] scgi and __del__ cleanup in publisher
>
>
>
> 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.
>