Re: GFileMonitor API improvments?

[Martyn Russell <martyn imendio com>]

Bastien Nocera wrote:
> On Mon, 2008-06-16 at 12:02 +0100, Martyn Russell wrote: 
>> 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.

I really think this is a non-issue. If I thought that the speed was
really an issue, I wouldn't be using the GIO monitor API. Even it if was
an issue, the benefits of using glib far exceed the minor performance
hit I am seeing at this point.

>>> 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?

Currently inotify has a "user" limit of 8192 by default, that's for ALL
applications per user as far as I understand.

Well, checking how many watches are already out there is quite
impossible to be accurate about especially if people use inotify
directly (unless the inotify API has been updated since I last looked at
it). But that's not really the point. If you know what the maximum is,
you can at least make sure you leave some room for others instead of
blindly doing it until a monitor fails.

>> 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.

You would expect to be able to find out to change your application's
behaviour accordingly.

-- 
Regards,
Martyn