[Tutor] Starbucks does not use two-phase commit

[Danny Yoo]

> I noticed that when I do a keyboard interrupt, I get the keyboard
> interrupt exception messages, but after that it keeps hangning and never
> returns to the command line input mode. I have to close the shell to
> really end the program afaics.

Hi Bernard,

When we're using the high-level 'threading' interface, the server thread
--- which runs independently of the main thread --- will continue to run
until it's shut down.  But we can call setDaemon() on the server's thread
to allow Python to exit.  Look at the bottom of:

    http://www.python.org/doc/lib/thread-objects.html

So we can modify server.startServer() to flag the server thread as a
daemon:

    def startServer(self):
        t = Thread(thread=self._jobLoop)
        t.setDaemon(True)
        t.start()



> While I have been using the thread module, using:
>
> thread.start_new( <function name>, ( <thread id>, <other args> ) )
>
> When I implemented your example in my program, I also used your
> approach, and started having the hanging behavior. I reconverted the
> thread spawn to my own approch, just to see if it would make a
> difference.

The low level 'thread' library is a bit more platform specific.  Here's
what the documentation says:

    (http://www.python.org/doc/lib/module-thread.html)

    """When the main thread exits, it is system defined whether the other
    threads survive. On SGI IRIX using the native thread implementation,
    they survive.  On most other systems, they are killed without
    executing try ... finally clauses or executing object destructors."""


Does this make sense?