Prev: tcl-snmptools
Next: ANNOUNCE: RamDebugger 7.0 released
From: Teemu Salmivesi on 15 Sep 2009 05:52 Hi, I have problems with response times of GUI while processing long running tasks like database transactions. Transactions are events and handled by the main loop using TCL_DoOneEvent function. The problem is that during a long running task the GUI is not able to handle mouse events like a motion event. From my application point of view it is not possible to split transactions or use threads. I have tested to use 'update' inside the long running task to refresh the GUI but it seems to have any effects to mouse events. http://wiki.tcl.tk/1526 I have tried to call TCL_DoOneEvent to handle all idle events and window events during a long running task, but it is not the solution for the problem. Any advice for the problem? How I am able to force Tk to catch all mouse events from X Window and handle events during a long running task? I am using TCL/TK version 8.4 on Solaris. - Teemu
From: Alexandre Ferrieux on 15 Sep 2009 06:18 On Sep 15, 11:52 am, Teemu Salmivesi <salmiv...(a)gmail.com> wrote: > > How I am able to force Tk to catch all mouse events from X Window and > handle events during a long running task? Simple: do your blocking stuff in a different thread or process. You mentioned threads not being an option; please elaborate. -Alex
From: Teemu Salmivesi on 15 Sep 2009 07:30 Hi, We have a very large application which is not planned to use threads and it is not thread safe. The application is event-based and we are handling io-events, windows events, ... in the same event loop. Within the event loop we are updating local data container in a one trasaction. During the update user wants to draw something on the canvas but we are not able to handle mouse events because of a long running task. Actually the application lost all those mouse motion events which should be created during the long running task. We found out that X Window is generating motion events but the sequence number of the event doesn't change during the task. What we want to do is to get mouse events from TCL/Tk during the task and draw the canvas occasionally. event loop{ TCL_DoOneEvent () { ... calls io_handler } } io_handler () { // do all db operations of a transaction for_each (db operation) { ... do stuff ... handle mouse events and draw a canvas } } - Teemu On 15 syys, 13:18, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > On Sep 15, 11:52 am, Teemu Salmivesi <salmiv...(a)gmail.com> wrote: > > > > > How I am able to force Tk to catch all mouse events from X Window and > > handle events during a long running task? > > Simple: do your blocking stuff in a different thread or process. You > mentioned threads not being an option; please elaborate. > > -Alex
From: Alexandre Ferrieux on 15 Sep 2009 08:04 On Sep 15, 1:30 pm, Teemu Salmivesi <salmiv...(a)gmail.com> wrote: > > We have a very large application which is not planned to use threads > and it is not thread safe. Then look at the contradiction in full light: either you manage to isolate your blocking transaction in another thread, or you'll have to do the finer-grained scheduling by hand (assuming you can split one long wait into several shorter-timeout operations). No way out. Note that isolating your database part in a separate *process*, if the needed I/O bandwidth permits, will save you the hassle of making anything thread-safe. It will morph the problem into one of serialization, which is way simpler. -Alex
From: Nick Hounsome on 15 Sep 2009 09:04
On 15 Sep, 10:52, Teemu Salmivesi <salmiv...(a)gmail.com> wrote: > Hi, > > I have problems with response times of GUI while processing long > running tasks like database transactions. > Transactions are events and handled by the main loop using > TCL_DoOneEvent function. > The problem is that during a long running task the GUI is not able to > handle mouse events like a motion event. > > From my application point of view it is not possible to split > transactions or use threads. Why not? Tcl itself is thread safe therefore you only have a problem if you call non-thread-safe code from two different threads. If you route everything to do with the database through Tcl to a single thread you shouldn't have a problem. This is a lot less bother than doing the essentially the same thing with a piped process. |