Re: GFileMonitor API improvments?
- From: Bastien Nocera <hadess hadess net>
- To: Martyn Russell <martyn imendio com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GFileMonitor API improvments?
- Date: Mon, 16 Jun 2008 16:12:55 +0100
On Mon, 2008-06-16 at 12:02 +0100, Martyn Russell wrote:
> Bastien Nocera wrote:
> > On Mon, 2008-06-16 at 11:45 +0100, Martyn Russell wrote:
> >> Hi all,
> >>
> >> For the Tracker project we need to know certain things when monitoring
> >> the file system depending on each backend used (inotify/fam/polling/etc).
> >
> > IMO, for something like Tracker, you're better off using the native
> > APIs, rather than glib's.
>
> Well, so far, I see no speed impairment using the GIO APIs and while
> that is the case, using an API which comes for free, is tested, bug
> fixed regularly, etc. is way better than supporting n backends ourself
> in Tracker.
There is bound to be some speed differences which might not be
significant with a low number of watches... Of course, those should be
minimal, and pure performance problems should be fixed, but I can't see
the GFileMonitor handling better than a bare-bones inotify.
> > The API in glib will always be the lowest common denominator between
> > what's possible on different platforms, and special casing based on the
> > backend is bound to create problems.
>
> While I agree in some part here, I also think there is no real problem
> with returning 8192 or -1 in an API which requests the maximum number of
> monitors, where -1 is whatever the documentation says it means (be it
> unlimited, unset, etc).
>
> I can understand that knowing what backend you are using is potentially
> very specific to Tracker though.
If only the maximum number of watches is needed, maybe an API could be
added. But would it be the per-program limit? Wouldn't it also need a
function to check the current number of watches?
> I should also add, knowing the backend is potentially very important for
> mobile & embedded devices, since applications often need efficiencies
> which the desktop doesn't and this is very "technology" specific.
You would expect embedded devices to have a glib with the "slow" methods
(like polling and FAM) disabled.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]