On Thu, Sep 29, 2011 at 12:05, Emmanuele Bassi <eba...@gmail.com> wrote:
> hi;
>
> On 29 September 2011 09:57, Andrew W. Nosenko
> <andrew.w.nose...@gmail.com> wrote:
>> On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist <t...@iki.fi> wrote:
>>> I would say, bah. Any actively maintained (or recently written)
>>> GLib-using code that doesn't use GIO by now is just being maintained
>>> or written in a misguided fashion.
>>
>> Tor, did I understand your position right that any program written in
>> the speed in minds and uses Glib is written in a misguided fashion?
>
> that's a fairly creative way of misinterpreting that sentence.
No, that is creative way to point author to avoid improper
generalizations and be more precise in phrases.
> if GIO is measurably slower at doing I/O than a stat(), please: file
> bugs along with profiling data.
GIO as layer is so comparable to stat() as apples comparable to
grapes, and we both know it :-)
But, unfortunatelly, all GMainLoop based stuffs (including GIO) are
indeed slow when we come to high workload if compared to kqueue based
(and I think epoll-based also) main loop implementations.
Therefore, either you use GIO, and limited to the current GMainLoop
speeds, or use something kqueue-based and have no way to GIO.
Fill Bugzilla? No needs, it's already done both years ago and quite recently:
https://bugzilla.gnome.org/show_bug.cgi?id=156048 ("epoll support
in gmain.c", 2004 year)
https://bugzilla.gnome.org/show_bug.cgi?id=657729 ("modernise
GMainLoop", 2011 year)
--
Andrew W. Nosenko <andrew.w.nose...@gmail.com>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
