After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 597946 - [GstPoll] Use glib's GPoll for portability
[GstPoll] Use glib's GPoll for portability
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Mac OS
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-09 19:55 UTC by Edward Hervey
Modified: 2012-08-13 23:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2009-10-09 19:55:19 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)
Comment 1 Daniel Macks 2009-10-10 06:36:09 UTC
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.
Comment 2 Edward Hervey 2009-10-11 07:48:59 UTC
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.
Comment 3 Jan Schmidt 2009-10-11 17:55:00 UTC
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.
Comment 4 Edward Hervey 2009-10-12 14:52:54 UTC
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.
Comment 5 Wim Taymans 2010-04-09 16:19:42 UTC
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).
Comment 6 LRN 2010-04-09 16:25:39 UTC
I guess, fixing upstream (glib) is not an option?
Comment 7 Tim-Philipp Müller 2012-08-13 23:11:34 UTC
Resolving as WONTFIX as per comment 5. There's another bug for the plugin loader issue.