Re: GFileMonitor API improvments?



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]