GNOME Bugzilla – Bug 692608
Wine needs custom thread support
Last modified: 2018-05-24 14:58:09 UTC
After http://mail.gnome.org/archives/commits-list/2011-September/msg03773.html, many games are broken under Wine. Wine uses gstreamer, when available, to play some audio/video files (if the codecs are installed in the native environment). After this change, however, those games fail to work. I've searched for bugs regarding custom threads, but did not see anything relevant. Downstream bug: http://bugs.winehq.org/show_bug.cgi?id=30557
I think that's because it was intentional. See http://mail.gnome.org/archives/commits-list/2011-September/msg03773.html http://mail.gnome.org/archives/gtk-devel-list/2011-August/msg00059.html http://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00003.html I think their position is that pluggable threads are just broken, and not worth the bother.
(In reply to comment #1) > I think their position is that pluggable threads are just broken, and not worth > the bother. Well, I think we also didn't know of anyone actually using it for anything other than debugging. Link to the code: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winegstreamer/glibthread.c It looks like for some reason they need to be using their implementations of the win32 thread functions for parts of it rather than using pthreads directly... the commit log doesn't explain why though so it's hard to say how else this might be fixed.
From #winehackers <aricstewart> yeah, i remember discussing this with someone. <aricstewart> I am not an expert with that, I do remember Maartin talking about it a lot with julliard when it was going in. <aricstewart> If i recall the issue is that gstreamer makes many threads and then calls into sinks from those threads, sink functions that end up in wine code that wants to do win32 sorts of things. <aricstewart> because they are threads not made by wine, wine would not have the info it needs and it caused problems. So Maartin used those hooks to ensure that all threads made by gstreamer would be proper wine threads. <aricstewart> not sure what more I can give you. Again, my understanding of the gstreamer half of that is pretty low, and this part also.
Pretty much that, what happens is that wine needs to initialize some TLS on the other segment register at thread creation time, and inform wineserver about it's existance. Similarly during thread shutdown, it needs to do a callback to inform wineserver about it and clean up those resources. If pthread functions are used directly, you end up with 2 or more threads that share the same win32 thread id, this causes chaos when attempting to do any win32 call, or performing any locking in wine. glibthread.c was just a copy from glib's win32 threading implementation, so I didn't change it much apart from removing some compability code iirc.
If all you need is TLS then just use GPrivate. On first access, assign a unique ID and then use the same ID in that thread from then on... When the thread is destroyed, the GDestroyNotify of the GPrivate will be called.
Yes, except that windows (and thus wine) uses the segment register that linux doesn't use. %fs on linux, %gs in wine. Or the other way around depending on whether you're on 64-bits or 32-bits. It also needs to use custom allocation functions for the stack itself, and notify all running dll's about the new thread that was just created before it starts running. It's really difficult to do so after the thread is already created though, so it would be easier to override the thread functions.
So would it be possible to make this work if g_thread_new() was the only function you could hook into?
Ideally pthread_join/exit overrides too
I don't know if this helps at all, but GStreamer informs the application about the creation/shutdown of streaming threads via STREAM_STATUS messages on the bus. See: http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-stream-status.txt You should be able to hook into this, and/or even provide your own custom way of creating threads using other API: http://cgit.freedesktop.org/gstreamer/gstreamer/tree/tests/examples/streams/rtpool-test.c http://cgit.freedesktop.org/gstreamer/gstreamer/tree/tests/examples/streams/testrtpool.c
This is still a major issue for Wine. Applications which require media format display or conversion have been broken since glib 2.32 (mid-2012), and there does not seem to be an acceptable way to do this without the old custom threading API. (In reply to Tim-Philipp Müller from comment #9) > You should be able to hook into this, and/or even provide your own custom > way of creating threads using other API: > > http://cgit.freedesktop.org/gstreamer/gstreamer/tree/tests/examples/streams/ > rtpool-test.c > http://cgit.freedesktop.org/gstreamer/gstreamer/tree/tests/examples/streams/ > testrtpool.c This is a good start, but doesn't cover all cases of glib threads calling back into Wine code. There is at least usage of g_thread_pool_push in gstreamer's <gst/gstbin.c> which we can't override. Tim suggested on IRC that gstreamer plugins may also create their own threads unknown to gstreamer, which may then call into Wine code. There does not seem to be an avenue for custom thread creation with glib 2.32 or later without resorting to really, really ugly hacks like overriding pthreads's methods.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/660.