How to handle mouse events during a long-running database transaction?
in [TCL]
|
Prev: tcl-snmptools
Next: ANNOUNCE: RamDebugger 7.0 released
From: Alexandre Ferrieux on 15 Sep 2009 09:18 On Sep 15, 3:04 pm, Nick Hounsome <nick.houns...(a)googlemail.com> wrote: > > Tcl itself is thread safe therefore you only have a problem if you > call non-thread-safe code from two different threads. No. Tcl is also upset if you call it from a thread different from the one bound to its interp, unless you go through the Async.3 API. > If you route everything to do with the database through Tcl to a > single thread you shouldn't have a problem. Wrong. In the envisioned setup, Tcl lives in thread A and DB in thread B. Even if the B thread calls into Tcl through Async.3, A's call into the DB will need a mutex or similar protection, which amounts to making the DB API thread-safe. > This is a lot less bother than doing the essentially the same thing > with a piped process. Matter of taste. All the nasties above vs. [fileevent] and serialization... -Alex
From: Donal K. Fellows on 15 Sep 2009 11:32 On 15 Sep, 14:18, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > Nick Hounsome wrote: > > Tcl itself is thread safe therefore you only have a problem if you > > call non-thread-safe code from two different threads. > > No. Tcl is also upset if you call it from a thread different from the > one bound to its interp, unless you go through the Async.3 API. To explain a bit more (and dissuade anyone from futilely trying to trick their way past), Tcl internally uses a lot of thread-local data so that it can avoid holding global locks where not necessary. This speeds things up a lot in a multi-threaded environment, but also means that attempting to use an interpreter from more than one thread will go horribly wrong, and the horrible wrongness will be unpredictable too. The only sane mechanism to avoid this task (dealing with blocking database updates) is to perform the updates from a separate thread that sends a message back to the main thread (there are several ways to do efficient inter-thread messaging) when the update is completed. Or, if you're really lucky, your database API will have a non-blocking interface which will let you do everything in a single thread; some database APIs do, but most don't. Donal.
From: tom.rmadilo on 15 Sep 2009 11:36 On Sep 15, 4:30 am, 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. I think I have identified the problem. But how exactly did you develop a non-thread safe application...in Tcl?
From: Teemu Salmivesi on 15 Sep 2009 12:54 On 15 syys, 15:04, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > 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. > I agree. The application includes c and c++ code about 5.000.000 lines. That means that an another thread is not easy to implement because the code is not thread safe as I mentioned earlier. The application has TCP/IP, UDP/IP connections, local memory database and the GUI. I know that the design of the application is not the best one, but the code is very efficient except the huge task which will update the local database thru the TCP/IP connection. We are planning to do scheduling by hand. Our plan is to interrupt the long running task (not always a db transaction) and handle mouse events so often that response of the GUI will be good enough. I know that there is a possibility to handle collapsed mouse events in Tcl but I don't know how to do it inside the TCL_DoOneEvent function. It seems that we are not able to get mouse motion events at all. Do you have any idea how to get mouse motion events from the event queue of Tcl? - Teemu > 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: tom.rmadilo on 15 Sep 2009 13:19
On Sep 15, 9:54 am, Teemu Salmivesi <salmiv...(a)gmail.com> wrote: > On 15 syys, 15:04, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> > wrote: > > > 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. > > I agree. > The application includes c and c++ code about 5.000.000 lines. > That means that an another thread is not easy to implement because the > code is not thread safe as I mentioned earlier. > The application has TCP/IP, UDP/IP connections, local memory database > and the GUI. > I know that the design of the application is not the best one, > but the code is very efficient except the huge task which will update > the local database thru the TCP/IP connection. > > We are planning to do scheduling by hand. Our plan is to interrupt the > long running task (not always a db transaction) and > handle mouse events so often that response of the GUI will be good > enough. I know that there is a possibility to handle collapsed mouse > events in Tcl > but I don't know how to do it inside the TCL_DoOneEvent function. It > seems that we are not able to get mouse motion events at all. > Do you have any idea how to get mouse motion events from the event > queue of Tcl? > > - Teemu > > > 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. Why not update the GUI via tcp/ip or udp? Usually a GUI is only a snapshot of the actual state (especially if you are using a database), so just decouple the GUI by using either a client poll or server push. Or maybe what you are saying is that your application makes a local copy of the data and then uses a long transaction to update the real database. If that is the case, the design issue is trying to synchronize two copies of essentially one chunk of data. That is risky and difficult. But if that is what is happening, you could make a copy of the data from your GUI application and then run an update from the copy (a headless version of your application) to the database, kind of like an auto-save feature, but it could avoid a GUI freeze (the exact same thing happens with your typical desktop application during an auto-save operation). |