On 09/02/15 12:53, Emmanuele Bassi wrote:
hi;
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 maintainable. 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.
-- Regards, Martyn _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
