Created attachment 89087 [details] [review]
Create a source that is triggered by pushing data to the queue

I'll admit to having polled GAsyncQueues from a GMainLoop in the past...

Compare with bug 626702

*** Bug 626702 has been marked as a duplicate of this bug. ***

Created attachment 292424 [details] [review]
gasyncqueue: add GAsyncQueue watch source

Add g_async_queue_watch_source_new(), etc, to allow creating a GSource
to watch for additions to a GAsyncQueue.

Based on an older patch from Chris Wilson.

As compared to the earlier patch, the biggest change is that this only calls the source callback if it actually manages to pop an item from queue, making the behavior saner in the case where there are multiple readers. (Oh, and it has tests.)


In bug 626702, Havoc had said:

> Anyway I don't know whether the "bunch of idles" solution makes this API
> unnecessary or not. It does seem clunky somehow.

My use case is that I have a thread emitting data, and a GInputStream implementation that will receive that data in another thread. The reader might be using either g_input_stream_read() or g_input_stream_read_async(), but the emitter has no reason to care which, so it seemed inelegant to need two different codepaths. With this, the emitter can just always do g_async_queue_push().

Comment on attachment 292424 [details] [review]
gasyncqueue: add GAsyncQueue watch source

>@@ -674,7 +692,7 @@ g_async_queue_length (GAsyncQueue *queue)
>   g_return_val_if_fail (queue, 0);
> 
>   g_mutex_lock (&queue->mutex);
>-  retval = queue->queue.length - queue->waiting_threads;
>+  retval = queue->queue.length - queue->waiting_threads - g_slist_length (queue->watches);

I'm now thinking this change is probably wrong... I had been thinking that it preserved consistency, but the point of the code in the synchronous case is that "three items, two waiting threads" will immediately collapse into "one item", and so subtracting out the number of waiting threads just hides a race condition that you don't need to care about. In the async case, it's uncertain how long it will take the watches to pop the queued items (and in some cases it's guaranteed that they won't pop them until after the current function returns), so subtracting them out is probably wrong.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/94.