Re: Review of gnio, round 1
- From: Behdad Esfahbod <behdad behdad org>
- To: Alexander Larsson <alexl redhat com>
- Cc: desrt desrt ca, gtk-devel-list <gtk-devel-list gnome org>, gicmo gnome org, danw gnome org
- Subject: Re: Review of gnio, round 1
- Date: Mon, 27 Apr 2009 10:40:43 -0400
On 04/27/2009 09:53 AM, Alexander Larsson wrote:
With gnome 2.26 out and the GResolver branch landed it is time to start
look at merging the gnio network code into gio. I'm posting this here,
plus CC:ing the involved people instead of on bugzilla in order to get
feedback from others who may be interested but unaware of this work.
There is a lot of G_UNLIKELY() calls in places that really are not in
any way performance sensitive. I'm not sure I like this, since it makes
the code harder to read for very little gain. Like, it probably makes
sense for the inlined version of g_once_init_enter() to use G_LIKELY,
but I don't think it makes sense for e.g. error checking when creating a
socket, which is not gonna happen a lot.
I think I can answer this part since I use G_UNLIKELY extensively myself. The
way I see it, it's not just a hint for the compiler, it's also an annotation
of the source code for the next person reading it, saying "this branch is
expected to happen in exceptional cases only, not the norm." And I find it
extremely useful for that.
Having e.g. g_io_stream_get_output_stream() fallback on the property in
case no vfunc is specified in the interface is IMHO pretty weird. A much
more natural way would be to have the property implemented in the common
code, based on the get_output_stream vfunc. This would be more efficient
and need less code in inheriting classes. However, this is only possible
if we change GIOStream to a baseclass instead of an interface.
Not sure I'm following. But wanted to point out making decisions based on
whether a vfunc is NULL is a very bad idea for bindings.
] [Thread Prev