GNOME Bugzilla – Bug 748495
libde265: No code to detect the number of CPUs on W32
Last modified: 2015-04-28 15:11:04 UTC
Results in #warning "Don't know how to get number of CPU cores, will use the default thread count"
Created attachment 302396 [details] [review]
libde265: W32 thread count support
Review of attachment 302396 [details] [review]:
Kind of a sad moment, since we got g_get_num_processors() since glib 2.36, but GST depends on 2.32 :-( Interestingly the glib implementation is much more complex, I wonder if there is a reason for this. Would it be possible to ask Ryan ?
if (GetProcessAffinityMask (GetCurrentProcess (),
unsigned int count;
for (count = 0; process_cpus != 0; process_cpus >>= 1)
if (process_cpus & 1)
if (count > 0)
@@ +43,3 @@
Most code I have been across uses G_OS_WIN32 for portability. Any reason this would not be right here ?
Created attachment 302448 [details] [review]
libde265: More elaborate W32 threadcount code from glib
Imports code from glib. This is more correct than a simple GetSystemInfo().
Apply on top of attachment 302396 [details] [review].
Attachment 302396 [details] pushed as 0a95a4e - libde265: W32 thread count support
I've squashed the patches, fix the use of _WIN32 to be G_OS_WIN32 and fixed the indentation. Please make sure gst-indent works, and don't use git commit -n option in further patch submission.
Refactored this a little so we can easily drop it when we bump glib requirement, let me know if it breaks anything on windows:
Author: Tim-Philipp Müller <firstname.lastname@example.org>
Date: Tue Apr 28 16:06:47 2015 +0100
de265dec: use g_get_num_processors() if available
And provide home-made fallback for older GLib versions,
so that we can later find these and remove them when
we bump the GLib requirement (which is certainly going
to happen before 2.0).
(On a side note, all this thread count autoconfig stuff looks highly dubious to me, as if nothing else is going on on the system..)