GNOME Bugzilla – Bug 597946
[GstPoll] Use glib's GPoll for portability
Last modified: 2012-08-13 23:11:34 UTC
Running suite(s): GstPoll 66%: Checks: 6, Failures: 2, Errors: 0 gst/gstpoll.c:207:F:general:test_poll_wait_restart:0: Write descriptor should be writeable gst/gstpoll.c:311:F:general:test_poll_controllable:0: Write descriptor should be writeable The problem seems to be well known ([0], [1]) and comes down to stdin/stdout/stderr being devices and not pipes on macosx ... and therefore not pollable (they return POLLNVAL straight away). The second link proposes a fix... but something tells me it's maybe not what we want. Shall we limit usage of GstPoll on macosx to fds different from stdin/stdout/stderr ? Shall we put a big fat warning ? Shall we make gst_poll_add_fd return false for 0/1/2 fds ? [0]: http://valhenson.livejournal.com/21031.html [1]: http://wiki.oriontransfer.org/snippets:poll_and_kqueue P.S. Steve, if you read this, just die ! sorry, I meant iDie (available with the latest iSuicide and it's iFailure extension pack)
How about implementing it using select() instead of poll()? glib has done this for years (OSX has never had a poll() that behaves completely compatibly to linux). Or just use their work: gpoll is a public interface that has the same API as poll() but is platform-portable internal implementation.
We currently depend on glib 2.18 (which was just bumped up), and GPoll was only added in 2.20. And yes, we should use the one from glib, the initial commit message for gstpoll (27th Feb 2008) contains the following "Add generic poll abstraction. We ideally don't want to have this in core here but in glib intead..." :) Changing the title accordingly. So basically... we should use glib's GPoll if we build against glib >= 2.20.
According to the docs, we will also need to be careful to pass file descriptors through GIOChannels to get things to work properly for all file descriptor types on win32. A couple of notes: * The new background plugin scanner uses GstPoll on stdin/stdout to pass messages back and forth. I didn't realise it was going to lead to these sorts of problems. Unfortunately, I also don't have any suggestions for ways to avoid it. * checking the file descriptor numbers isn't going to be effective - the first thing the background plugin scanner does is dup stdin/stdout onto different file descriptor numbers, but they are still attached to the same pipes.
I fixed the various issues for macosx, by detecting broken poll, making it use select instead... and a couple of other ugly fixes. I'm still leaving the bug open since we *should* switch to gpoll and the new gstpluginloader should swith to GIOChannels.
gstpoll does a lot more than gpoll, it creates, for example, a socketpair for interrupting a pending poll operation. There is also stuff for restarting the poll operation when GPollFDs were added etc). The only thing that could possibly be changed is the gst_poll_wait() function so that it calls gpoll instead. That would however not be so optimal because gpoll takes a timeout in milliseconds and we need nanoseconds precision (or at least microseconds).
I guess, fixing upstream (glib) is not an option?
Resolving as WONTFIX as per comment 5. There's another bug for the plugin loader issue.