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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Jan 8 18:40:48 PST 2010


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

--- Comment #34 from LRN <lrn1986 at gmail.com> 2010-01-09 02:40:44 UTC ---
The long-term solution is to wait until certain version of GLib and use GPoll
instead of GstPoll.
GstPoll+my_big_patch and GPoll are different in following ways:
1) My poll uses asynchronous pipes (when coupled with my implementation of
spawn()), which work without threads (synchronous pipes + threads are also
supported). GPoll uses normal synchronous CRT pipes with threads for
anynchronousness
2) My implementation of spawn() uses Windows process handles instead of process
IDs, thus eliminating the problem with CRT incompatibility (process ID returned
by g_spawn*() are supposedly only waitable/closeable with waitpid/close of the
same version of MSVCRT). It might be fixable on GLib side if they provide
g_close() and g_waitpit() (do they?)
3) My patch doesn't work with GSource at all, because GSource polls sources
internally and there is no way to substitute that poll with my own.
4) My patch is my patch, GPoll is supposedly maintained by GLib developers
5) Migration from GstPoll to GPoll is easier than migration from GstPoll to
GstPoll+my_big_patch (especially considering the lack of GSource integration)

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