Re: [gtk-list] Long non-GUI tasks

[Havoc Pennington <hp redhat com>]

On Wed, 22 Sep 1999 lightmanaj@earthlink.net wrote:
> 
> I'm faced with a potentially sticky situation. I need to make an API 
> call to an external library which may possibly last on the order of 
> magnitude of seconds to minutes. I do not maintain this library, so 
> I can't place any gtk_main_iteration() calls anywhere *within* the 
> library function in question.
>

Ugh. This basically means you have to use another process or 
another thread...
 
> So my plan was to open a small progress box and display a 
> message, indicating that this will take some time. However, if I call 
> the function immediately after showing the progress box using 
> gtk_widget_show(), the contents of the box are not displayed! I 

What happens is that the box isn't rendered by GTK until it appears
on-screen, which happens asynchronously (i.e. you fire off a request to
the X server to display it, and when it finally displays an expose event
comes back).

The only way to know it's been displayed is to connect to expose_event,
basically.

However, even if you hack this to work it won't really work, because if
the progress window gets obscured and re-shown, GTK won't be able to
redraw it. Which will look like your app has crashed.

> Is there a way to handle this situation in a clean way? I tried 
> looking into GNU Pth for possible threading means, but it does not 
> support preemptive threads (otherwise this problem won't be 
> solved).
> 

pthreads should work OK, with some cost in portability/complexity...
glibc has pthreads, though.

Havoc