how to start a new thread from a GUI

[Donn Cave]

Quoth Wen Jiang <wj691781 at bcm.tmc.edu>:
| Donn Cave wrote:
|> 
|> Quoth Wen Jiang <wj691781 at bcm.tmc.edu>:
|>| I have a GUI to submit a background job and want the GUI to exit after
|>| the job is submitted to leave the actually big job run for a few days to
|>| compleletion. Could anyone give me a hint how to do this? right now the
|>| GUI stays but blocked by the background job.
|>| Thanks.
|> 
|> os.spawnv(os.P_NOWAIT, cmd, argv) might work for you.
|
| The job is a class method in python, not a standalone program, os.spawnv
| might not work with this situation. is it still doable with other
| techniques (fork, thread ?)

Oh.  Well, I believe that depends on your GUI implementation.

I'm most familiar with the BeOS interface these days.  There I would
execute the computational job from a non-window thread - possibly the
main thread, which normally just hangs around doing nothing.  It could
equally well run in its own special thread, but either way the main
thread must survive while any other threads are around, and the
application interface state associated with the main thread will
survive along with it.  The interface windows could all close, but
the application icon will still be visible in the application menu.

On UNIX, you would be using X11, and the visible X11 graphics state
is tied to a file descriptor opened by the client, connecting to the
display server.  On program exit the file descriptor naturally closes
and all that state is cleared, and in theory you can close that
connection from the program without exiting, to the same effect.
In practice I don't know how easy that will be from your particular
toolkit.  I see Chris Liechti shows how to get the threads running
for this experiment, and the rest is up to you.

But I would instead try to fork a separate process.  From the fork
I would close the X11 connection file descriptor and perhaps all other
open file descriptors, effectively detaching the fork from the parent
program.  The parent can proceed, and exit normally when convenient.
Of course the fork should never "return", so you should put a
try/finally around it to prevent that.

	Donn Cave, donn at u.washington.edu