[gstreamer-bugs] [Bug 597662] Windows-incompatible changes in gstreamer

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Nov 27 18:52:44 PST 2009


https://bugzilla.gnome.org/show_bug.cgi?id=597662
  GStreamer | gstreamer (core) | git

LRN <lrn1986> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #147559|0                           |1
        is obsolete|                            |
 Attachment #147561|0                           |1
        is obsolete|                            |

--- Comment #27 from LRN <lrn1986 at gmail.com> 2009-11-28 02:52:40 UTC ---
Created an attachment (id=148632)
 View: https://bugzilla.gnome.org/attachment.cgi?id=148632
 Review: https://bugzilla.gnome.org/review?bug=597662&attachment=148632

Limited POSIX-compatible I/O and process spawning API, implemented on top of
WinAPI

It's big, it's bad...it works.

I've made it like this:
1) Look up POSIX specs
2) Look up WinAPI specs
3) Implement
4) Test on pluginloader (which was the focus of this patch)
5) Fix until pluginloader works
5) Test on unit tests
6) Fix until unit tests affected by it do work [again (because some of them
weren't working in the first place)]

Which means that in its present condition this code is correct (mostly) in
relation to GStreamer code and its unit tests, but not POSIX as it is. That is
why i left it in form of #ifdefs instead of replacing POSIX/glibc syscalls with
something like gst_io_read() or whatever. The intention is for programmers to
be painfully aware of the fact that there are two different I/O interfaces with
roughly the same logic, but with possible differences in behaviour in some
cases (in which case it must be fixed).

Some things are not implementable (at least i didn't find a way to do it). For
example, it is not possible to check a pipe for closiness without actually
reading or writing data (writing or reading 0 bytes doesn't help). Because of
that gst_win32_prepare_for_poll does a clever thing - it looks at polled
events: if there are no events other than POLLHUP (FD_CLOSE), it reads or
writes (depends on handle access) 1 byte. Normally that would screw up the
communication process, but since application obviously expects pipe to be
closed, it doesn't matter if we write garbage or waste data by reading it. But
application should be aware of it to avoid unpleasant surprises.

Another thing - i didn't do a descriptor table. Which means that there are no
'0', '1' and '2' descriptors matching stdin/out/err. This is obvious in some of
the unit tests where two functions rely on the fact that fd = 1 is always the
same fd. To make it work, i had to create a wrapper (because this is how it
works) WinFd structure in one function and pass it to the other function via
global variable to make sure that the other function uses the same pointer.

Hacky things:

return values (especially the painful 64-bit file seeking). Some functions may
return signed values instead of unsigned. Be careful.

fd as gpointer. It might be dangerous because while gpointer is big enough to
hold any fd, it is unsigned, while fd is signed. If you see '== (gpointer) -1'
- it really was '< 0'.

Some unit tests will continue to fail. I guess they were failing before too.
Unless i know exactly what exactly is being tested (tests are known to produce
a lot of warnings/errors because they sometimes do bad things on purpose, so
just fixing errors is not correct - i have to know which errors are intended
and which aren't) i can't rectify that.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list