how to start a new thread from a GUI

Andrae Muys amuys at shortech.com.au
Fri Aug 24 04:00:05 CEST 2001


Wen Jiang <wj691781 at bcm.tmc.edu> wrote in message news:<3B7B2CE4.E33809F7 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.
> 

My last job was writing a program identical to this.  Put simply, you
are barking up the wrong tree, your GUI should not be tied to the
compuational process at all.

The simplest approach is to write a command-line application that
reads a parameter file and writes a result file.  Preferably this
application would default to stdin/stdout in the traditional unix
pattern.

Then have your GUI spawn the command-line program as an independent
process.

In the end we ended up with a slightly more complex architecture that
had the GUI use a CORBA nameservice to find persistant-daemons running
on compute-servers, that fork/exec'd the command-line simulations in
response to "simulate requests", tracked their progess, and reported
on their status.

I left for my current employer before we completed the entire system,
but after we got the basic design above working.

Of course we also left in the option of spawning the process locally
from the GUI, or running it directly from a script/CLI.

This sort of flexibility (from script/CLI to CORBA based load-balanced
compute-server farm) is immediately available if remember to keep your
simulation seperate from your interface.

HTH, GL.

Andrae Muys



More information about the Python-list mailing list