After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 322537 - Deadlocks in inotify_monitor_add() when using threads
Deadlocks in inotify_monitor_add() when using threads
Status: RESOLVED FIXED
Product: libinotify
Classification: Deprecated
Component: general
CVS HEAD
Other Linux
: Normal normal
: ---
Assigned To: Libinotify Maintainer(s)
Libinotify Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2005-11-26 23:49 UTC by Sylvain Pasche
Modified: 2005-12-01 19:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Sylvain Pasche 2005-11-26 23:49:20 UTC 
inotify_monitor_add() sometimes calls itself recursively while holding the
intify_monitor_lock. Thus, it deadlocks.

Without calling g_thread_init(NULL), the G_LOCK call does nothing. That's why we
only see the problem after calling g_thread_init(NULL).
Comment 1 Allison Karlitskaya (desrt) 2005-11-27 00:05:58 UTC 
oh how I wish we had reentrant locks in glib.  thinking about how to fix this. 
suggestions welcome but as far as i can see there are 2 real possibilities:

1) create reentrant locks for ourselves
2) have a "don't lock" bit in the 'flag' field that gets set when libinotify
calls itself
Comment 2 Allison Karlitskaya (desrt) 2005-12-01 19:07:04 UTC 
We _do_ have these locks in glib.  I just didn't know about them.

Using them now.  Thanks for the report.