From: SourceForge.net <no...@so...> - 2007-12-04 12:31:55
|
Bugs item #1842856, was opened at 2007-12-02 14:09 Message generated for change (Comment added) made by pragmatic_lee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1842856&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: External Functions Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Miesfeld (miesfeld) Assigned to: Nobody/Anonymous (nobody) Summary: CPU 100% when ooDialog program started through explorer Initial Comment: Rick, This is just a copy and paste of the CPU 1005 problem I talked about on the devel list. It may very well be that this has the same root cause as some of the other excessive CPU bugs. I thought it best to just open up a new bug and track what I know for sure. I have tracked down a repeatable way of pegging the CPU at 100%, and a hack that fixes it. Scenario: ------------- Any ooDialog program. Program extension is .rex, ftype association is the default of .rex associated with rexx.exe. A good example is the sample.rex program. If you double click on the icon of the program, either on the Desktop or in explorer, the rexx process and the rxapi process will use 100% of the CPU. The CPU is split between the 2, but not evenly. rexx.exe takes more than rxapi. On a dual processor system (including dual core) the CPU is 50 %. (Which makes sense of course, one processor is maxed out, the other is free.) If you start the same ooDialog program from the command line, CPU is normal, always. If you start the ooDialog program using rexxhide, CPU is normal. For rexxhide, what I mean is that if .rex is associated with rexxhide instead of rexx, then double clicking on the program icon does not use excessive CPU. Or if you set up the icon to start the ooDialog with rexxhide instead of rexx then CPU is normal. Hack / work around: ----------------------------- In plbdlg.cls you have the run method. If I add in a do-nothing start, the problem completely goes away. As far as I can tell, always. ::method Run unguarded protected use arg sleeptime if Arg(1,'o') = 1 then sleeptime = 0 msgObj = self~start("workAround") <-- add drop msgObj <-- add do while self~finished = 0 self~HandleMessages(sleeptime) end ::method workAround <-- add empty method In private e-mail I have had a 3 people verify both the repeatability of the problem and that the work around fixes it. ---------------------------------------------------------------------- >Comment By: Lee Peedin (pragmatic_lee) Date: 2007-12-04 07:32 Message: Logged In: YES user_id=1223125 Originator: NO Mark, I just attempted to duplicate this and was partially successful. On a dual processor system I see CPU usage from 17% to 30% on an ooDialog program that I created myself that "has buttons". If I execute a "static" dialog, I see no CPU usage at all once the dialog is displayed. When running the sample.rex program I see from 22% to 37% cpu usage. I also noticed that when running sample.rex, there was a "delay" on clicking the Exit button or the X in the upper right corner. Also, I see no difference with sample.rex after modifying pbldlg.cls as you described above. It's been a while since I rebooted, so will reboot and try the tests again. Lee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1842856&group_id=119701 |