From: Teemu Salmivesi on
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
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
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
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
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.
 |  Next  |  Last
Pages: 1 2 3
Prev: tcl-snmptools
Next: ANNOUNCE: RamDebugger 7.0 released