Re: Long running DBI queries == no GUI interaction

[Grant McLean <grant mclean net nz>]

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.

Cheers
Grant