On Mon, Feb 09, 2015 at 12:53:46PM +0000, Emmanuele Bassi wrote: > hi; > > On 9 February 2015 at 12:40, Debarshi Ray <rishi...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
