Re: Long running DBI queries == no GUI interaction

On Wed, 2004-11-24 at 10:29, Jan Hudec wrote:
On Wed, Nov 24, 2004 at 10:17:11 +1300, Grant McLean wrote:
I want to have my perl-gtk app query a database using DBI and 
display the query results.  Some of the queries can take minutes 
to run and a naive implementation would mean all GUI interaction 
was blocked until the $dbh->execute returned.

Is this a solved problem?  I can envisage a fairly simple 
workaround that involves forking a child to run the query and 
passing the results back over a pipe or socket using IO events, 
but obviously would prefer not to write the code if there's an 
existing solution.

First of all, it is an obvious problem. When it's not threaded and
a function waits for something, so does whole application.

Now, there are two possibilities:

1) Asynchronous query. I don't know whether DBI can do this, though.

I could be wrong, but I think this is one of the things planned for DBI
2.  I know DBD::Pg has a way of getting the socket file descriptor for
use with select(), but I don't think there's a way to do that sort of
thing that isn't driver-specific.  Yet.

2) Threads. Perl can do threads. Just you have to be careful and only
   access the GUI from one thread. The older versions of perl-Gtk2 were
   not thread-safe and I am not sure how well it works in the new ones
   (IIRC it should).

Hmm, I guess that should work.  One of the advantages of using Gtk's
event loop though is that it generally allows one to avoid threads.  My
past experiences with Perl threads has not led me to consider them as
the first option. It is certainly an option though if no event loop
friendly solution exists already.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]