Loading ...
Sorry, an error occurred while loading the content.

4210Re: a fix for the multi-core bug in the windows build

Expand Messages
  • sect62
    Apr 11 10:38 AM
    • 0 Attachment
      Thanks a ton for the help guys.

      Dave, did you have any other instability with the stock binary besides the crash on shutdown, like multiple menus or occasional unresponsiveness?

      Bill, Looks very consistent and good to see there isn't any unexpected behavior. I have a few hyper-v hosts (win2k3 and win2k8r2) here that I have tested on and seen the same results. I'd say that covers the architecture spectrum pretty well. Well enough to consider this patch to be generally safe.

      I also tested the un-patched stock build on dual core XP 32-bit. I see the behavior that Steve saw where most activity is on core zero. This makes me think XP's scheduler just isn't very good at spreading load, which turns out to be a benefit in this scenario.

      You mentioned not hard-coding the core number. I guess that'd have to be a command-line switch. I don't see any other way to intercept the process early enough before threads start spawning.


      --- In frontierkernel@yahoogroups.com, "u074036" <u074036@...> wrote:
      > I don't know much about thread programming, but I can reproduce the issue here on my quad-code Lenovo T510 running Windows 7 (an infinite script loop fully spikes 2 of my 4 processors). I can also demonstrate the "crash on shutdown" behavior (although I have my own work-around for that - a specialized shutdown procedure that make sure all threads except the primary one are shut down before the program exits). I'll be happy to test for you any time you like. Although I typically run "Frontier" and not "OPML", I can switch easily, or compile the changed code into my copy of Frontier.
      > Dave H
    • Show all 19 messages in this topic