in reply to Re: Long-running DB query makes Tk application unresponsive
in thread [solved] Long-running DB query makes Tk application unresponsive

Hm, my communication skills are letting me down again. The retrieval of the rows is not slow. The end result set is only about 10-15 rows on average, but the gymnastics to get them in SQL is terribly complex. I had our DBA guys optimize the SQL, but even so it takes several minutes just to *start* returning rows, even in SQL*PLUS, for example.

As to making a reusable thread, I've lately been toying with the idea of having a long-running process act as some kind of IPC server, and having the GUI just be a client of that. The client might look something like: 

$res = $srvr->ask($SQL,@params);
if ($res == SRVR_ACK && SRVR_WAIT) {
   # set up something to check back for results later
}
else {
   # deal with the results
}

[download]

I think that's kinda-sorta what you're talking about, but I just can't seem to wrap my head around this, so I might be wrong. Thoughts?

<-radiant.matrix->
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law

Replies are listed 'Best First'.
Re^3: Long-running DB query makes Tk application unresponsive
by zentara (Cardinal) on Oct 14, 2005 at 18:47 UTC
    As far as making a reusable thread, see ztk-BBC-World-News-Rss-TickerTape and look at the sub work. It is a sleeping thread, which gets turned on by the shared variable $shash{'go'} and is killed by $shash{'die'}. So you can create the thread, (or a couple of them), wake them with a go=1, and let them do whatever you want. When done, set go=0. The sleep 1 gives a very efficient sleep, but you can remove the 1 second lagtime, by using a smaller sleep time with something like "select,undef,undef,undef,100" for a 100 microsecond delay.
    I'm not really a human, but I play one on earth. flash japh
[reply]

In Section Seekers of Perl Wisdom