Delay a computation in another thread

[eryk sun]

On Fri, Sep 8, 2017 at 10:03 AM, Thomas Jollans <tjol at tjol.eu> wrote:
> On 2017-09-08 16:49, Steve D'Aprano wrote:
>
>> Sorry for the long delay in replying to this, but if I set its daemon attribute,
>> won't that mean it will live on after the interpreter shuts down?
>>
>> Also, what happens if it tries to print after the interpreter shuts down? Where
>> does output go?
>
> On Linux, I think it would go to the same virtual terminal as it did
> before, if that still exists. (Otherwise, to /dev/null). This is how
> processes that started out attached to a terminal and then went into the
> background normally behave.

In the normal case, when the interpreter shuts down, the process exits
along with all threads. On the other hand, when Python is embedded,
daemon threads may persist if the interpreter is finalized without
exiting the process. Such threads shouldn't be able to do anything
because they'll block trying to acquire the GIL.

> No idea what happens on Windows, but if I had to guess, I'd say "not that".

The Windows console system (i.e. condrv.sys driver, conhost.exe host,
and csrss.exe session server) doesn't have full support for Unix-style
process groups. They're supported for targeting Ctrl+C and Ctrl+Break.
Also, Ctrl+C is disabled for new process groups. But there's no notion
of foreground and background process groups. Thus it can't implement
the Unix feature that suspends a background process that tries to read
from console input. (Usually background processes in Unix are allowed
to write to the terminal, but that can be disallowed as well.)

In the CMD shell, the closest you can do for running a process in the
background is via "start /b [...] <nul", i.e. create a new process
group that disables Ctrl+C and redirect its stdin to NUL. If you don't
redirect stdin, the child will compete with CMD to read from the
console.