On Thu, Feb 18, 2010 at 8:51 PM, Erich Hoover ehoover@mines.edu wrote:
Real Name: Erich Hoover Description: The attached patch adds a test for SetThreadAffinityMask(thread,-1), which succeeds on Windows Vista and newer. This "all processors" flag is not documented, but was discovered tracking down another issue. Please see the wine-devel thread for more information: http://www.winehq.org/pipermail/wine-devel/2010-February/081879.html ChangeLog: kernel32/tests: Add test for 'all processors' flag on Vista and newer.
The test shouldn't query the Windows version explicitly. Instead, the older return value on pre-Vista version should be denoted by the broken() macro.
On Thu, Feb 18, 2010 at 8:29 PM, Andrew Nguyen arethusa26@gmail.com wrote:
On Thu, Feb 18, 2010 at 8:51 PM, Erich Hoover ehoover@mines.edu wrote:
... The attached patch adds a test for SetThreadAffinityMask(thread,-1), which succeeds on Windows Vista and newer. ...
The test shouldn't query the Windows version explicitly. Instead, the older return value on pre-Vista version should be denoted by the broken() macro.
Then the test could only be triggered in Wine. What if this "feature" gets removed again in some later version of Windows?
Erich Hoover ehoover@mines.edu
Then the test could only be triggered in Wine. What if this "feature" gets removed again in some later version of Windows?
broken() only applies to Windows versions, Wine never succeeds with a broken feature. It really is what you want. --Juan
On Thu, Feb 18, 2010 at 8:45 PM, Juan Lang juan.lang@gmail.com wrote:
Then the test could only be triggered in Wine. What if this "feature" gets removed again in some later version of Windows?
broken() only applies to Windows versions, Wine never succeeds with a broken feature. It really is what you want. --Juan
I'm not arguing with the behavior of broken(). I'm saying that since this feature is undocumented it's entirely possible that it could get removed in some future version of Windows*, so if we're not testing the version we wouldn't know that it got removed. We were lucky to stumble upon this thing in the first place, it's starting to look like it's not actually the issue responsible for the slowdown bug for which we are researching.
Erich Hoover ehoover@mines.edu
* Though I doubt it, as this seems like a sneaky way to make people believe that their multi-threaded apps run slower on XP,
I'm not arguing with the behavior of broken(). I'm saying that since this feature is undocumented it's entirely possible that it could get removed in some future version of Windows*, so if we're not testing the version we wouldn't know that it got removed. We were lucky to stumble upon this thing in the first place, it's starting to look like it's not actually the issue responsible for the slowdown bug for which we are researching.
Except that an app already depends on the newer behavior, so Microsoft would have to maintain a quirk for the app if they wanted to change the behavior. Since the hypothetical future version of Windows with changed behavior doesn't yet exist, addressing that case seems rather premature. --Juan
On Thu, Feb 18, 2010 at 8:59 PM, Juan Lang juan.lang@gmail.com wrote:
I'm not arguing with the behavior of broken(). I'm saying that since this feature is undocumented it's entirely possible that it could get removed in some future version of Windows*, so if we're not testing the version we wouldn't know that it got removed. We were lucky to stumble upon this thing in the first place, it's starting to look like it's not actually the issue responsible for the slowdown bug for which we are researching.
Except that an app already depends on the newer behavior, so Microsoft would have to maintain a quirk for the app if they wanted to change the behavior. Since the hypothetical future version of Windows with changed behavior doesn't yet exist, addressing that case seems rather premature. --Juan
Point taken.
Erich Hoover ehoover@mines.edu
-
Andrew Nguyen -
Erich Hoover -
Juan Lang