polling in the inotify code, II

[Matthias Clasen <mclasen redhat com>]

Here is another (untested) patch which attempts to
address the second part of the problem, but only doing
the 8-times a second timeout for delayed event processing
if there are any events to process.

Matthias


Index: inotify-kernel.c
===================================================================
RCS file: /cvs/gnome/gnome-vfs/modules/inotify-kernel.c,v
retrieving revision 1.7
diff -u -p -r1.7 inotify-kernel.c
--- inotify-kernel.c	11 Dec 2005 20:33:46 -0000	1.7
+++ inotify-kernel.c	27 Jul 2006 14:51:43 -0000
@@ -59,6 +59,8 @@ static gboolean ik_process_eq_callback (
 static guint32 ik_move_matches = 0;
 static guint32 ik_move_misses = 0;
 
+static guint timeout_id = 0;
+
 /* We use the lock from inotify-helper.c
  *
  * There are two places that we take this lock
@@ -111,8 +113,6 @@ gboolean ik_startup (void (*cb)(ik_event
 	event_queue = g_queue_new ();
 	events_to_process = g_queue_new ();
 
-	g_timeout_add (PROCESS_EVENTS_TIME, ik_process_eq_callback, NULL);
-
 	return TRUE;
 }
 
@@ -416,6 +416,12 @@ static gboolean ik_read_callback(gpointe
 		buffer_i += event_size;
 		events++;
 	}
+
+	if (!q_queue_is_empty (event_to_process) && timeout_id == 0) {
+		timeout_id = g_timeout_add (PROCESS_EVENTS_TIME, 
+					    ik_process_eq_callback, NULL);
+	}
+	  
 	G_UNLOCK(inotify_lock);
 	return TRUE;
 }
@@ -576,12 +582,13 @@ ik_process_events ()
 		g_queue_push_tail (event_queue, event->event);
 		/* Free the internal event structure */
 		g_free (event);
-
     }
 }
 
 gboolean ik_process_eq_callback (gpointer user_data)
 {
+	gboolean retval;
+
     /* Try and move as many events to the event queue */
 	G_LOCK(inotify_lock);
     ik_process_events ();
@@ -593,6 +600,14 @@ gboolean ik_process_eq_callback (gpointe
 		user_cb (event);
 	}
 
+	if (g_queue_is_empty (events_to_process)) {
+		timeout_id = 0;
+		retval = FALSE;
+	}
+	else {
+		retval = TRUE;
+	}
 	G_UNLOCK(inotify_lock);
-	return TRUE;
+
+	return retval;
 }