I'm not sure hoe much I like this proposal, though I could be convinced.
Is the problem here that the %SS takes too long? If so, how about spawning off multiple MUPIPs to run in parallel?
Also, how about being able to provide a pid for immediate %SS? Often we know which process we want to look at and the rest is not important.
My concern is that stale data would lead to disastrous red herrings. The scenario I can see is that there's a client listener that does READ^XWBRW (?) about 99% of the time and so it's lowered in priority. You run a test using the client and do ^%SS simultaneously. You can't count on the results from the %SS being recent if the daemon has decided to "nice" it way back down. You would need a way to say "Seriously, I mean it, do %SS for pid xyz, now!"
I'm not sure hoe much I like this proposal, though I could be convinced.
Is the problem here that the %SS takes too long? If so, how about spawning off multiple MUPIPs to run in parallel?
Also, how about being able to provide a pid for immediate %SS? Often we know which process we want to look at and the rest is not important.
My concern is that stale data would lead to disastrous red herrings. The scenario I can see is that there's a client listener that does READ^XWBRW (?) about 99% of the time and so it's lowered in priority. You run a test using the client and do ^%SS simultaneously. You can't count on the results from the %SS being recent if the daemon has decided to "nice" it way back down. You would need a way to say "Seriously, I mean it, do %SS for pid xyz, now!"