Fix an invalid non-looping use of GCond

The GIOScheduler was using a GCond in a way that didn't deal with the
possibility of spurious wakeups.  Add an explicit predicate and a loop.

Problem caught by Matthias Clasen.

https://bugzilla.gnome.org/show_bug.cgi?id=660739
This commit is contained in:
Ryan Lortie 2011-10-04 11:07:15 -04:00
parent c474cd71ba
commit 449a1e8bfd

View File

@ -278,6 +278,7 @@ typedef struct {
GMutex ack_lock; GMutex ack_lock;
GCond ack_condition; GCond ack_condition;
gboolean ack;
} MainLoopProxy; } MainLoopProxy;
static gboolean static gboolean
@ -291,6 +292,7 @@ mainloop_proxy_func (gpointer data)
proxy->notify (proxy->data); proxy->notify (proxy->data);
g_mutex_lock (&proxy->ack_lock); g_mutex_lock (&proxy->ack_lock);
proxy->ack = TRUE;
g_cond_signal (&proxy->ack_condition); g_cond_signal (&proxy->ack_condition);
g_mutex_unlock (&proxy->ack_lock); g_mutex_unlock (&proxy->ack_lock);
@ -347,7 +349,8 @@ g_io_scheduler_job_send_to_mainloop (GIOSchedulerJob *job,
g_source_attach (source, job->context); g_source_attach (source, job->context);
g_source_unref (source); g_source_unref (source);
g_cond_wait (&proxy->ack_condition, &proxy->ack_lock); while (!proxy->ack)
g_cond_wait (&proxy->ack_condition, &proxy->ack_lock);
g_mutex_unlock (&proxy->ack_lock); g_mutex_unlock (&proxy->ack_lock);
ret_val = proxy->ret_val; ret_val = proxy->ret_val;