Re: GFileMonitor limit or g_signal_connect() connexions handling ?

[Olivier Delhomme <olivierdelhomme gmail com>]

2014-02-24 14:45 GMT+01:00 Aleksander Morgado <aleksander gnu org>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 21/02/14 22:48, Olivier Delhomme wrote:
> I'm using Glib 2.26 and I'm playing a bit with GFileMonitor. I'm trying to
> monitor several
> directories. It seems that the system works fine for a few directories (123
> for instance)
> but this does not work with more directories (19350 for instance).
>
> Basically I'm using g_file_monitor call. The call does not raise any error.
> Then I connect
> a callback function to the "changed" signal of each monitor. I seems that
> this function is
> not called when there too much directories monitored. Yo can see my code
> here :
> https://github.com/dupgit/sauvegarde/blob/master/monitor/monitor.c
>
> I'm trying to understand what is happening.
>
> Is there a limit to the numbers of monitored directories ?
> How are handled those signal connections to the callback function ?

Assuming you're running under Linux, you'll be using the inotify based
backend in the GFileMonitor. If that is the case, you're likely hitting
the max number of watches per inotify instance, specified in:
  /proc/sys/fs/inotify/max_user_watches

You can modify that value in runtime, e.g.:
  echo 16384 > /proc/sys/fs/inotify/max_user_watches

Or to make it permanent, add the following to /etc/sysctl.conf
  fs.inotify.max_user_watches=16384

Thanks for your answer,

You're right. I discovered that, on my system, the GFileMonitor limit

is at 1024 and the inotify one is at 8192.

The weird thing is that GFileMonitor interface does not warn by

raising an error... inotify says that "the disk is full" (the raised

error is strange but there is an error....). One would expect the

GFileMonitor to raise an error when file descriptors are exhausted.

Cheers,

Olivier.