On tor, 2015-02-12 at 12:55 -0800, Philip Chimento wrote:
On Thu, Feb 12, 2015 at 5:22 AM, Philip Withnall
phi...@tecnocode.co.uk wrote:
On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote:
On ons, 2015-02-11 at 12:17 +, Philip Withnall wrote:
On Thu, 2015-02-12 at 12:55 -0800, Philip Chimento wrote:
On Thu, Feb 12, 2015 at 5:22 AM, Philip Withnall
phi...@tecnocode.co.uk wrote:
On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote:
On ons, 2015-02-11 at 12:17 +, Philip Withnall wrote:
On Wed, Feb 11, 2015, at 02:33 PM, Jim Nelson wrote:
One of Philip's earlier suggestions was to print a console warning if
a sync call is used. That seems like overkill to me, but it does lead
to another possibility.
Technically the issue is long synchronous calls blocking the event
loop,
On Fri, 2015-02-13 at 04:52 -0500, Colin Walters wrote:
On Wed, Feb 11, 2015, at 02:33 PM, Jim Nelson wrote:
One of Philip's earlier suggestions was to print a console warning
if a sync call is used. That seems like overkill to me, but it does
lead to another possibility.
On Fri, Feb 13, 2015 at 09:33:24AM +, Philip Withnall wrote:
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
Anybody have any thoughts about option #3? I’m wary about filling the
docs up
On 09/02/15 12:53, Emmanuele Bassi wrote:
hi;
Hi, :)
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
On ons, 2015-02-11 at 12:17 +, 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
On Thu, Feb 12, 2015 at 5:22 AM, Philip Withnall phi...@tecnocode.co.uk
wrote:
On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote:
On ons, 2015-02-11 at 12:17 +, Philip Withnall wrote:
I understand where you’re coming from; we should not be irritating
experienced
On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote:
On ons, 2015-02-11 at 12:17 +, 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
On Wed, 2015-02-11 at 11:33 -0800, Jim Nelson wrote:
One of Philip's earlier suggestions was to print a console warning if
a sync call is used. That seems like overkill to me, but it does lead
to another possibility.
Emmanuele refined that to printing a warning if G_ENABLE_DIAGNOSTIC is
On Wed, 2015-02-11 at 13:10 -0800, Jasper St. Pierre wrote:
That's one example of low-hanging fruit. Calling query_info_async is
the same thing. Creating a GFileMonitor for a GResourceFile
(admittedly nonsense, but arbitrary code that tries to watch any GFile
passed into it might hurt) will
One of Philip's earlier suggestions was to print a console warning if a
sync call is used. That seems like overkill to me, but it does lead to
another possibility.
Technically the issue is long synchronous calls blocking the event
loop, but in practice the problem is GTK+'s events being
On Wed, Feb 11, 2015 at 2:46 PM, Ray Strode halfl...@gmail.com wrote:
Hi,
On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall phi...@tecnocode.co.uk
wrote:
It might turn out that runtime checks are just not feasible, but in that
case I think we still need some way of solving the original
On 11/02/15 21:10, Jasper St. Pierre wrote:
Another example: for some odd reason, GLocalFileInputStream isn't a
pollable output stream
(I assume you mean GLocalFileOutputStream.)
Why was this done? I don't know.
AIUI, because all Unix kernels treat local I/O as arbitrarily fast,
hence
On Wed, 2015-02-11 at 21:26 +, Simon McVittie wrote:
On 11/02/15 21:10, Jasper St. Pierre wrote:
Another example: for some odd reason, GLocalFileInputStream isn't a
pollable output stream
(I assume you mean GLocalFileOutputStream.)
Why was this done? I don't know.
AIUI, because
That's one example of low-hanging fruit. Calling query_info_async is the
same thing. Creating a GFileMonitor for a GResourceFile (admittedly
nonsense, but arbitrary code that tries to watch any GFile passed into it
might hurt) will call query_info_async once every 5 seconds, creating a new
thread
On Tue, 2015-02-10 at 08:49 -0800, Jasper St. Pierre wrote:
Right now the way g_file_read_async works is by scheduling a task on a
worker thread, having the worker thread do the async read, and then
returning a result.
As such, it's impossible to have two async reads done at the same
time,
On Tue, 2015-02-10 at 10:30 -0800, Jasper St. Pierre wrote:
One quick example: calling g_file_read_async on a GResourceFile spawns
a new thread and does a synchronous stream read from a block already
in memory.
It should just be a single g_bytes_ref, but we have three different
classes
On Tue, 2015-02-10 at 15:48 +0100, Lennart Poettering wrote:
Also, glib has wrappers for making mmaping available to programs, to
improve seldom-accessed sparse databases efficient, do you want to
prohibit that too?
No, mmap() is clearly a tool for a different kind of problem. If
On Tue, 10.02.15 13:59, Philip Withnall (phi...@tecnocode.co.uk) wrote:
I am pretty sure if you do async IO like gio does for every single
file access you'll just complicate your program and make it
substantially slower. For small files normal, synchronous disk access
is a ton faster than
Right now the way g_file_read_async works is by scheduling a task on a
worker thread, having the worker thread do the async read, and then
returning a result.
As such, it's impossible to have two async reads done at the same time,
which is really unfortunate from my understanding. If I'm reading
On Mon, 09.02.15 10:47, Philip Withnall (phi...@tecnocode.co.uk) wrote:
Hi all,
From some feedback from real-world users of GLib/GIO (see the ‘Feedback
from downstreams’ thread), and just from looking at our own code in
GNOME, it seems that people persistently use sync versions of APIs in
On Mon, 2015-02-09 at 14:55 +0100, Bastien Nocera wrote:
On Mon, 2015-02-09 at 13:42 +, Philip Withnall wrote:
On Mon, 2015-02-09 at 14:02 +0100, Bastien Nocera wrote:
On Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote:
snip
I do agree with Philip's proposal of warning if
On Tue, 2015-02-10 at 11:20 +0100, Lennart Poettering wrote:
On Mon, 09.02.15 10:47, Philip Withnall (phi...@tecnocode.co.uk) wrote:
Hi all,
From some feedback from real-world users of GLib/GIO (see the ‘Feedback
from downstreams’ thread), and just from looking at our own code in
One quick example: calling g_file_read_async on a GResourceFile spawns a
new thread and does a synchronous stream read from a block already in
memory.
It should just be a single g_bytes_ref, but we have three different classes
created, a thread spawned, and a large amount of locks to do the
On Mon, 2015-02-09 at 10:57 +, Debarshi Ray wrote:
On Mon, Feb 09, 2015 at 10:47:37AM +, Philip Withnall wrote:
I guess there are two approaches: making async APIs easier to use; and
discouraging use of sync ones. I think the GAsyncResult framework we?ve
got is pretty good, and I
- Original Message -
On Mon, Feb 09, 2015 at 10:47:37AM +, Philip Withnall wrote:
I guess there are two approaches: making async APIs easier to use; and
discouraging use of sync ones. I think the GAsyncResult framework we?ve
got is pretty good, and I can?t think of a way to
guess there are two approaches: making async APIs easier to use; and
discouraging use of sync ones. I think the GAsyncResult framework we’ve
got is pretty good, and I can’t think of a way to simplify it.
(Suggestions welcome.)
For discouraging use of sync APIs, I have two strawman ideas:
1. Hide
On Mon, Feb 09, 2015 at 10:47:37AM +, Philip Withnall wrote:
I guess there are two approaches: making async APIs easier to use; and
discouraging use of sync ones. I think the GAsyncResult framework we?ve
got is pretty good, and I can?t think of a way to simplify it.
One convention that I
On Mon, Feb 09, 2015 at 12:53:46PM +, 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 +, Philip Withnall wrote:
On Mon, 2015-02-09 at 10:57 +, Debarshi Ray wrote:
One convention that I like is
On Mon, 2015-02-09 at 13:42 +, Philip Withnall wrote:
On Mon, 2015-02-09 at 14:02 +0100, Bastien Nocera wrote:
On Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote:
snip
I do agree with Philip's proposal of warning if the sync API is called
inside the default main context, even
On Mon, Feb 09, 2015 at 06:52:13AM -0500, Ondrej Holy wrote:
We already have g_file_read_async, it was probably typo, however
I wonder which methods doesn't have async versions? Would be probably
good start to implemented them if there are any.
I meant that currently:
- g_file_read_async is
Aha, sorry for misunderstanding. You are right, this is sad.
Regards
Ondrej
- Original Message -
On Mon, Feb 09, 2015 at 06:52:13AM -0500, Ondrej Holy wrote:
We already have g_file_read_async, it was probably typo, however
I wonder which methods doesn't have async versions? Would
On Mon, 2015-02-09 at 14:02 +0100, Bastien Nocera wrote:
On Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote:
snip
I do agree with Philip's proposal of warning if the sync API is called
inside the default main context, even if there's the obvious issue of
console-only code that still
On Mon, Feb 09, 2015 at 11:14:46AM +, Philip Withnall wrote:
On Mon, 2015-02-09 at 10:57 +, 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
hi;
On 9 February 2015 at 12:40, Debarshi Ray rishi...@lostca.se wrote:
On Mon, Feb 09, 2015 at 11:14:46AM +, Philip Withnall wrote:
On Mon, 2015-02-09 at 10:57 +, Debarshi Ray wrote:
One convention that I like is to use a _sync suffix for sync APIs,
instead of an _async suffix for
On Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote:
snip
I do agree with Philip's proposal of warning if the sync API is called
inside the default main context, even if there's the obvious issue of
console-only code that still uses a main loop, but does not have
interactivity issues.
I
On Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote:
I do agree with Philip's proposal of warning if the sync API is called
inside the default main context, even if there's the obvious issue of
console-only code that still uses a main loop, but does not have
interactivity issues.
38 matches
Mail list logo
