dvfs api and toolkits

Waldo Bastian bastian at kde.org
Mon Apr 4 11:53:27 EEST 2005

On Monday 04 April 2005 03:54, Owen Taylor wrote:
> On Sun, 2005-04-03 at 21:34 -0400, Avery Pennarun wrote:
> > On Sun, Apr 03, 2005 at 09:20:41PM -0400, Owen Taylor wrote:
> > > On Sun, 2005-04-03 at 18:37 -0400, Sean Middleditch wrote:
> > > > It is entirely possible to build a synchronous wrapper around an
> > > > asynchronous API, but not the other way around.  The method to do so
> > > > is basically along the lines of: begin operation, set callback in
> > > > toolkit event loop, run toolkit loop, check if operation is complete,
> > > > repeat loop if not complete.  The most important bit here is the
> > > > toolkit part - doing a synchronous API is dependent on the toolkit
> > > > (or, more accurately, the event loop) of the application.
> > >
> > > A synchronous API *must not* recurse the main loop.
> >
> > I'm pretty sure that's not true of all toolkits.  In some, for example,
> > dialog boxes are implemented by explicitly calling the event loop after
> > blocking certain kinds of events.
> The point is not that the main loop cannot be recursed, but that
> recursing the main loop when the app isn't expecting it will result
> in hard-to-debug, obscure, bugs. A synchronous API must block with
> no side effects until the call completes.

I guess it depends on the application, but for GUI apps its very convenient to 
have a synchronous API that keeps the event loop alive. You are completemy 
right of course to say that if the app isn't expecting it, it will result in 
hard-to-debug, obscure bugs. The solution to that is to make sure that the 
app knows about it. In KDE our synchronous VFS operations basically emulate a 
modal message box, in fact putting up an actual (semi-) modal progress dialog 
might not be a bad idea. Is that the best solution? No, a full asynchronous 
solution will work better, but it will also require quite a lot more effort 
on the side of the application.

> GTK+ handles recursive main loop calls just fine. It's not a toolkit
> issue.
> If there is a synchronous API at all, it should be designed for non-GUI
> apps and threaded apps. A single threaded GUI app should be using only
> asynchronous APIs. (*)
> Regards,
> 						Owen
> (*) One thing that needs to be thought through carefully is what happens
>     with the synchronous API if an authentication dialog needs to be
>     displayed. This is a big problem with gnome-vfs.

That's not a problem if you do it in a different process. If I understand 
sean's proposal correctly, that would be the daemon process.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050404/73484f3e/attachment.pgp 

More information about the xdg mailing list