Re: Discouraging use of sync APIs

[Debarshi Ray <rishi is lostca se>]

On Mon, Feb 09, 2015 at 12:53:46PM +0000, Emmanuele Bassi wrote:
> 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.

I see. Thanks for clearing that up.

Cheers,
Debarshi