Re: _wstat on Windows (actually stat stuff in general)
- From: "Andrew W. Nosenko" <andrew w nosenko gmail com>
- To: Emmanuele Bassi <ebassi gmail com>
- Cc: Tor Lillqvist <tml iki fi>, gtk-devel-list gnome org
- Subject: Re: _wstat on Windows (actually stat stuff in general)
- Date: Thu, 29 Sep 2011 12:44:13 +0300
On Thu, Sep 29, 2011 at 12:05, Emmanuele Bassi <ebassi gmail com> wrote:
> On 29 September 2011 09:57, Andrew W. Nosenko
> <andrew w nosenko gmail com> wrote:
>> On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist <tml 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)
GMainLoop", 2011 year)
Andrew W. Nosenko <andrew w nosenko gmail com>
] [Thread Prev