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
irritating
> > 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
gstdio
> 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
gstdio-like
functions for local file I/O though, which would tend to be
integrated
nicely?
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:
https://bugzilla.gnome.org/show_bug.cgi?id=744458
Anybody have any thoughts about option #3? I’m wary about filling the
docs up with big red warnings.
Philip
Attachment:
signature.asc
Description: This is a digitally signed message part