Re: Discouraging use of sync APIs

On 09/02/15 12:53, Emmanuele Bassi wrote:

Hi, :)

whne GDBus was introduced, as its primary author, David made the
executive decision to follow the default-async/explicit-sync pattern
because most of the applications dealing with DBus for IPC were GUI
applications using asynchronous API to avoid blocking the main loop.
not many people were using DBus in threads, because neither dbus-glib
nor any other wrapper around it was thread safe. the existing code
base was already used to callback-heavy approaches.

I thought at the time GIO started this convention for file operations that sync APIs should be second class citizens to async APIs (i.e. the reverse for how it is currently). Saying that, perhaps that doesn't suit the lower level APIs so well.

The other reason is that GLib is quite heavily related to GTK+ and people should be encouraged (i.e. stubs should be async first) to use a core API that fits better with a UI that can not afford to block on I/O. I've also personally preferred to avoid threading unless necessary.

it's unfortunate that both GFile and GDBus share the same namespace,
thus making the API look inconsistent. both approaches have their own
downsides; using threads to perform long running synchronous
operations is not at all bad these days, thanks to GTask. it's
actually much easier to spawn a GTask and deal with I/O (both file
operations and IPC) synchronously, instead of tracking the state over
a ton of callbacks. personally, that's how I've been writing I/O heavy
code for the past couple of years, as it makes my code much more

I do agree with Philip's proposal of warning if the sync API is called
inside the default main context, even if there's the obvious issue of
console-only code that still uses a main loop, but does not have
interactivity issues.

Yes, Android has something like this, which is quite sensible and would save users from disappointment from time to time I suspect.


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