[gstreamer-bugs] [Bug 520808] GstPoll's API could need some changes for Windows

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=520808

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #13 from Ole André Vadla Ravnås  2008-03-17 00:19 UTC -------
Wim: That sounds much better! I'll write up a patch for that.

However, there's another issue of far greater significance that I realized
while trying to port rtspsrc to Windows (which I decided to port solely because
it would be a better acid-test for GstPoll than udpsrc -- given that libcheck
turned out to take way more time to port to Windows than what I feel like
spending on it right now in order to run the GstPoll test-suite).

A summary of the discussion on IRC and the proposed solution follows:

<oleavr> wtay: I'm not sure how to fix GstPoll.. the Windows semantics are
weird. when you tell Winsock "when one of these events occur on this socket,
signal this event" through WSAEventSelect and you wait()
(WaitForMultipleObjects) and it gets signaled, you then have to figure out
which of the events occured by calling WSAEnumNetworkEvents.. however, that
clears the internal network event records on the socket and resets the event..
so if you try to wait for the same event again immediately after that, it will
time out / wait forever.. you have to issue a read()/write() etc. to actually
re-enable it
<oleavr> now one could then do a dummy read()/write() or similar for each such
condition to re-enable it, but if the GstPoll user then does a read()/write()
as well and then wait(), it will signal as a consequence of the dummy operation
and not the actual operation thereafter
<oleavr> in other words, I'm not sure how I can properly emulate the
select()/poll()/etc. semantics on Windows
(...)
<wtay> oleavr, we need something that can wait on whatever it is that windows
uses for sockets, multiples of them with a timeout and then see what happened
<oleavr> wtay: that part is easy, the tricky part is waiting twice in a row,
because a wait changes the internal socket state
<MikeS> oleavr: could GstPoll keep additional state internally (the info it
gets from WSAEnumNetworkEvents?), and avoid waiting on things that it knows are
available right now, or something like that?
<oleavr> MikeS: well, it already stores the result of each WSAEnumNetworkEvents
after a successful wait, the problem is that such a call has the side-effect of
clearing the internal socket event, and taking the role as GstPoll you won't
know if the user did an operation that could change that state between two
successive calls to gst_poll_wait
<MikeS> ah, I see.
<MikeS> So basically, you don't know when to reset whatever it stores from
WSAEnumNetworkEvents?
<MikeS> Because that doesn't go through the GstPoll API at all
<oleavr> MikeS: yep, if only WSAEnumNetworkEvents didn't clear the internal
network event records of the socket until the next so-called 're-enabling
event' like recv/send/etc.
<oleavr> a hack would be to issue appropriate re-enabling calls according to
which were set, before leaving gst_poll_wait, but then the next gst_poll_wait
will give you the result of the dummy operation's completion
<MikeS> oleavr: so the only other way around this would be for those other
calls (recv, etc) to go through GstPoll, so it could reset things, etc. That
would suck too.
(...)
<wtay> oleavr, can't we just say that all sockets with activity needs to be
handled (on windows), which is usually a good thing to do anyways
<oleavr> wtay: that's a possibility.. the reason I ran into this is that
gstrtsp does 'connect' as: [socket () -> make it nonblocking -> connect() ->
gst_poll_wait(WRITE) -> yay, connected!], followed by 'send' being:
[gst_poll_wait(WRITE) -> send ()], where the two consecutive waits screws
things up :)
<MikeS> wtay: or add a function to say "I have not acted upon this thing" for a
given FD - so for every socket with activity, you either have to do something,
or call that function


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=520808.