OK, so now the possible root cause description...this is based on the last change I made and the DAY/NIGHT type of a difference I am seeing here.
If we go back a few months ago the FF 45.x release was starting to gain a bit of movement, to the point where I deemed it stable enough to move from 38.x to the test 45.x builds. One thing that has plagued us in that 45.x release is the CPU spikes issue, or specifically how after extended use (about 5 hrs here) the system just appears to literally slow down to a crawl to a point where only a FF process kill and re-start will get things back up and moving.
OK, so why does this matter?
Well, back then as my 5 cores would get 100% pegged and system became unresponsive I thought I should follow the recommendation of the XWP Help book and adjust the 'Worker thread' setting to the next higher value from the default, which is "idle +31". This means that I set this to 'regular'.
The XWP Help specifically states:
"...For most purposes, you should leave this setting to the default value, which is "idle +31". This will allow the Worker thread to perform its tasks in the background without a noticeable slowdown of the user interface. However, if you frequently run processes which hog up your CPU (that is, if your CPU load is always 100% because of, e.g., certain Windows applications running), you might want to raise this to "regular"..."
Now, as I was reviewing this and watching the various thread priorities I started questioning whether something was causing a race-type condition...or perhaps a much simpler priority driven "incompatibility". This idea popped into my head as I was reviewing the OS/2 Toolkit documentation and specifically looking at the MARKEXE documentation and how code design decisions impact execution in a SMP enviornments (remember, I previously noticed that disabling the 4 of y 5 cores seemed to produce a working environment where the problem was not occuring).
Here is the specific section of the MARKEXE information:
"...The following compatibility's requirements should be considered before running an application in multi-processor mode:
An application or associated subsystem must not use the 'INC' instruction as a semaphore without prepending a 'LOCK' prefix. On a UniProcessor (UP) system this instruction can be used as a high-performance semaphore without calling any other operating system service if the semaphore is free and when the semaphore is clear and there are no waiters for the semaphore. Because the INC instruction cannot be interrupted once started, and because the results would be stored in the flags register which are per thread, then it could be used safely as a semaphore.
In an OS/2 for SMP environment, this technique will not work because it is possible that two or more threads could be executing the same INC instruction, receiving the same results in each processor's or thread's flag register and thinking that they have the semaphore..."
Alright, to make it clear, I did not use MARKEXE to flag XWP as SMP un-safe, I am merely showing the above as a point of information.
So with this XWP Thread Worker change made, and getting me back to the XWP default priority setting what am I seeing? Well, I have several folders open, System Drives object, single Drive object and so on. None of them (so far, knock on wood...LOL) are running into this problem, and for me that is absolutely GREAT news!!!
I am not saying this has gotten me a working sytem, but in previous instances the folders would typically stop working in a manner of 5-10 mins...in other situations, they would be OK for several hours and than all of a sudden - BRICK WALL!
My machine has been up and running, with some pretty heavy FS use for a tad over 24 hrs...I will provide further updates as some additional time lapses and I have had the opportunity to re-boot and try several iterations. I've attached a screenshot of the 'XWorkplace Setup' object showing the Threads tab. Notice that the Worker thread is lower priority than SplitPopulate, previously though it would have been the same priority.
For now though, Rich, does this help out in any way in terms of what may be going wrong if one forces the higher priority?