[Baypiggies] On Python Design

Alex Martelli aleax at google.com
Thu Mar 6 01:23:55 CET 2008


I should clarify what I mean, apparently: you can just call
atexit.register from the __init__ of the "cool" object AFTER you
instantiate the monitor object, since in the parent process does that
initialization return to the caller.

On Wed, Mar 5, 2008 at 4:13 PM, Glen Jarvis <glen at glenjarvis.com> wrote:
> Alex,
>     I'm sorry this isn't coming across clearly, let me try this again
>  - but shorter (and hopefully more clear).
>
>  The API attached in the previous email forks two processes. This means
>  three total processes are running at any one time. If we register the
>  self.close() function, it will be executed three times (once for each
>  process). I can avoid some of this by how I exit: (os._exit(1))
>  instead of sys.exit.
>
>  I can also make a 'NormalExit' function, and re-register it at the
>  times that processes are spawned, but this solution is not very
>  elegant. In fact, it feels like I'm hacking to get this to work
>  (although I believe I could).
>
>  So, my over-all question is about the design approach. What have you
>  (or another reading this message) come across when mixing Object
>  Orientation, modules, atexit, and forked processes.

OO vs modules really has nothing to do with it.  Each forked process
should see to its own termination cleanup (if any) by calling
appropriate atexit.register.

>  I believed Object Orientation was a very nice way to approach this.

I disagree -- initializing a class exactly once and having its only
instance "just go away immediately" makes not much sense to me when
one can simply call a function instead -- the kind of thing one ends
up doing in a language that "forces" OO design, like Java, not
appropriate in a multiparadigm language allowing both objects and
functions, like C++ or Python.  But, that's not really connected to
the atexit/fork issue, one way or another.

>  However, it is no longer feeling so clean. It's starting to look
>  "Ugly" to use Guido speak...
>
>  Does this help explain my concerns?

Not really -- why not do the obvious thing (ensuring atexit.register
is only called in the parent process after the fork)?


Alex


More information about the Baypiggies mailing list