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