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

[GStreamer (bugzilla.gnome.o. <bug...@gn...>]

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

--- Comment #6 from LRN <lr...@gm...> 2009-10-09 09:52:08 UTC ---
1) It works. When external loader fails, it falls back to the old plugin loader
and still works.

2) Problem is that PluginLoader uses g_spawn*() to create the subprocess and
pipes to communicate with it, and wraps these pipes into GstPoll. The pipes
returned by g_spawn_async_with_pipes() are lowlevel CRT pipes, (_pipe() and
friends) and do not support asynchronous I/O. With WinAPI pipes
(CreateNamedPipe() and friends) it should be possible to do asynchronous I/O
and thus it should be possible to wrap them into GstPoll (after GstPoll is
extended to work with these pipes), but that also means either implementing a
version of g_spawn*() and friends that work with such pipes (which is what glib
developers should have done), or not using g_spawn*() at all.

As a sidenote, the same goes for files. With CRT file I/O you can't do
asynchronous I/O (AFAIK, i may be wrong), but with WinAPI file I/O you can. In
the end the usage of WinAPI I/O (as it was done with sockets in GstPoll) can
lead to uniform higher-level I/O API that supports async I/O, events and
various stuff. Of course it also means that there will be either separate
object files with implementation for *nix and for Win32, or a lot of #ifdefs
(kinda like GstPoll at the moment).

-- 
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.