Martin v. Löwis wrote:
Also, if the interpreter invokes, say, threading._shutdown():
that's also user-screwable, as a user may put something else
into threading._shutdown.
Although it would require being somewhat more deliberate,
since threading._shutdown clearly has something to do
with
[Martin v. Löwis]
In bug #1566280 somebody reported that he gets an
exception where the logging module tries to write
to closed file descriptor.
Upon investigation, it turns out that the file descriptor
is closed because the logging atexit handler is invoked.
This is surprising, as the
Tim Peters schrieb:
Upon investigation, it turns out that the file descriptor
is closed because the logging atexit handler is invoked.
This is surprising, as the program is far from exiting at
this point.
But the main thread is done, right?
Wrong. main.py (which is the __main__ script in
[Martin v. Löwis]
Upon investigation, it turns out that the file descriptor
is closed because the logging atexit handler is invoked.
This is surprising, as the program is far from exiting at
this point.
[Tim Peters]
But the main thread is done, right?
[Martin]
Wrong. main.py (which is the
Tim Peters schrieb:
Sorry, I couldn't follow the intent there. Not obvious to me how
moving this stuff from `threading` into `thread` would make it
easier(?) for the implementation to wait for non-daemon threads to
finish.
Currently, if you create a thread through the thread module
(rather
[Tim Peters]
Sorry, I couldn't follow the intent there. Not obvious to me how
moving this stuff from `threading` into `thread` would make it
easier(?) for the implementation to wait for non-daemon threads to
finish.
[Martin v. Löwis]
Currently, if you create a thread through the thread
In bug #1566280 somebody reported that he gets an
exception where the logging module tries to write
to closed file descriptor.
Upon investigation, it turns out that the file descriptor
is closed because the logging atexit handler is invoked.
This is surprising, as the program is far from exiting
