Re: Discouraging use of sync APIs

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 9 February 2015 at 12:40, Debarshi Ray <rishi is lostca se> wrote:
> On Mon, Feb 09, 2015 at 11:14:46AM +0000, Philip Withnall wrote:
> > On Mon, 2015-02-09 at 10:57 +0000, Debarshi Ray wrote:
> > > One convention that I like is to use a _sync suffix for sync APIs,
> > > instead of an _async suffix for async ones, because it lets me spot
> > > synchronous calls with grep.
> > >
> > > A little sad that there are things like g_file_read that are sync, not
> > > async.
> >
> > We had a brief discussion about that at the DX hackfest, and I think the
> > consensus was that the current naming scheme (no suffix = sync, ?_async?
> > suffix = async) is unfortunate, but has to be kept for consistency
> > reasons. It would be really confusing to switch to a new scheme while
> > keeping the old one. :-(
>
> There is really no consistency at the moment. eg., see
> g_dbus_proxy_new and the code generated by gdbus-codegen. It differs
> from class to class and module to module.

there's a pattern, but it's neither communicated nor discernible.

the file operations (which are the oldest ones in GIO) follow the
default-sync/explicit-async pattern; in general, sync file operations
on local storage are not terrible, even after going through a layer of
indirection, and the applications dealing with remote storage were a
minority when the API was introduced. few applications had to deal
with both at the same time — namely, Nautilus — and those were already
using threads internally, or async callbacks.

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.

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.

maybe we could use G_ENABLE_DIAGNOSTIC for this kind of messages;
after all, we're already using it for deprecated properties and
signals.

ciao,
 Emmanuele.

ciao,
 Emmanuele.

-- 
https://www.bassi.io
[ ] ebassi [ gmail com]