Re: Sharing Tk-module objects in threads

While you got several answers to your question, I'd like to point out that you might be trying to use Tk in a way that's not very natural.

You normally set up the way you want your application to look (initially) at application startup and then enter the mainloop, which is then *supposed* to block. Things then happen because of "external events", which you already declared and mapped to callbacks.

If you are for example writing a filemanager, things happen because you press buttons or select files from a list and these activate their corresponding callback. If you are writing something like an IRC client, things happen because you get I/O events on the irc socket, or the user fills in a text box and presses enter. These then again trigger their corresponding callbacks. If you are writing a monitoring application that shows the state of something every X seconds, you normally set up a repeat that collects that information, displays it and goes to sleep again until the next time. Callbacks again.

Only quite rarely do you need something that keeps running *all the time* and then for example periodically updates the display to show its progress. If your case is like that, a seperate process or thread might indeed be a very sane thing to do. But even for these the more normal solution is to chop up the work in small pieces and make a subroutine that every time it gets called does a piece of the work still pending. Then you arrange for this routine to be called as an idle callback (or as a repeat with timeout 0 if it's *very* high priority). No threading or forking needed if you do it this way, but the price you pay is that you have to "invert" your work so that it's driven by callbacks. For complex operations this is usually easiest done by writing the work in terms of a state machine. While it sounds a bit complex, in reality I tend to find it easier than managing a separate process/thread, especially since everything will happen "synchronous", so you usually don't have to worry about things like synchronization and locking

Comment on Re: Sharing Tk-module objects in threads

Replies are listed 'Best First'.
Re^2: Sharing Tk-module objects in threads by JamesNC (Chaplain) on Nov 05, 2004 at 12:34 UTC
I liked your comments, but say I have a long running sql query using DBI which blocks. Do you think you could demonstrate your technique using with a long running DBI query inside of Tk that would work on a Win32 machine? The main window will not refresh while DBI runs unless you separate that process somehow. I have a hack that works, but I am interested in seeing an example of what you are saying. Thanks so much! JamesNC	[reply]
Re^3: Sharing Tk-module objects in threads by thospel (Hermit) on Nov 05, 2004 at 12:51 UTC
Unfortunately the case you are describing there is indeed one that can't be solved in the normal callback style. That assumes you can split up the work in pieces that never block for a long time. A long running query invalidates that assumption. So for that case you must indeed use a separate process/thread or use an event driven database library (which means not directly using DBI. Even though there are plans for it, DBI is currently not event driven). Though even in the case of a separate process I'd normally set up a socket or pipe style connection between the GUI process and the DBI process and handle the socket/pipe events with I/O callbacks at the GUI side. The DBI side would probably be straightfoward code doing blocking calls.	[reply]