Re: GFileMonitor limit or g_signal_connect() connexions handling ?

2014-02-24 14:45 GMT+01:00 Aleksander Morgado <aleksander gnu org>:
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 :
> 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:

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

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.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]