Re: Discouraging use of sync APIs

On Thu, 2015-02-12 at 12:55 -0800, Philip Chimento wrote:
On Thu, Feb 12, 2015 at 5:22 AM, Philip Withnall
<philip tecnocode co uk> wrote:
        On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote:
        > On ons, 2015-02-11 at 12:17 +0000, Philip Withnall wrote:
        > >
        > > I understand where you’re coming from; we should not be
        > > experienced developers. I completely agree.
        > >
        > > What do you think of the proposal to use sync gstdio.h for
        > > small/local/pseudo-file-system I/O and async GIO for all
        other I/O?
        > I don't think this is a great alternative in many cases. The
        > stuff may work fine from C, but the GObjects etc of gio
        makes such use
        > much nicer from language bindings.
        True. Wouldn’t the languages typically have their own native
        functions for local file I/O though, which would tend to be

Javascript doesn't; one of the main reasons behind the decision to
make JS the first-class citizen for new Gnome apps developers was
precisely that it didn't already have its own platform. I got the
impression that using, for example, Python's native local file I/O
facilities in the Gnome stack was to be discouraged.

Bother, good point. Scrap that idea then.

In summary, options we’ve discussed so far are:
 1. Use gstdio.h for small reads, GIO async for others:
   - gstdio.h is rubbish from bindings
 2. Warn if sync API is used from the main context, enabling the warning
    on G_ENABLE_DIAGNOSTIC, and only warning if the call takes too long:
   + Helps in tracking down bugs at the source (rather than just ‘GTK+
     is being blocked too long’) 
   + Shouldn’t have any false positives in the cases discussed so far
     (small reads from console programs, application startup)
   - Requires active effort to enable (G_ENABLE_DIAGNOSTICS), limiting
     its uptake
 3. Rearranging the docs to promote async functions more
   ? Has not been discussed
   - Big red warnings in the docs may just be ignored by people

Seems like option #2 is worth going ahead with. I’ve filed:

Anybody have any thoughts about option #3? I’m wary about filling the
docs up with big red warnings.


Attachment: signature.asc
Description: This is a digitally signed message part

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