GNOME Bugzilla – Bug 677770
GUnixOutputStream does not implement can_poll
Last modified: 2012-06-20 14:16:11 UTC
Because of this, GPollableOutputStream.can_poll() always return TRUE, even for FDs from regular files. This is problematic because it means that GOutputStream.write_async() will block the calling thread if the underlying fd is not pollable at all. Things still work, it's just that your calling thread is blocked even when you are using the async function. Curiously enough, GUnixInputStream does not suffer from this problem (it implements can_poll just fine).
fixed. thanks
Thanks for fixing it. I wonder if we should have tests for all the known GInputStream and GOutputStream implementations to check that they do the right thing, e.g. that read_async() and write_async() doesn't block the calling thread. (The side-effect that made me find this bug was that the GUI main-loop was blocked and the idle scheduled by calling gtk_widget_queue_draw() wasn't calling until after the IO was done (I later switched my code to just using blocking read(2) and write(2) on the fd in a thread)... so, yeah, this is indeed possible to test.)
I added some can_poll() assertions to tests/pollable