Re: Discouraging use of sync APIs

On Mon, Feb 09, 2015 at 12:53:46PM +0000, Emmanuele Bassi wrote:

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

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.


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