On May 2, 2013, at 2:50 PM, Igor Stasenko <siguc...@gmail.com> wrote:
> On 2 May 2013 09:54, Henrik Johansen <henrik.s.johan...@veloxit.no> wrote: >> What? >> I am 99.99% sure it used to interrupt the GUI process if no other viable >> candidate could be found, why change that? >> At least in my mind, if you hit cmd - dot, either you want to interrupt some >> process blocking the UI on a higher priority, or you want the UI process >> itself. >> For everything else, there's the Process Browser. >> > > It was never like that. > It was always looking for a process which is scheduled, but not > interrupt process itself. > usually that meant it interrupts things like finalization process, > so i added logic to avoid interrupting it unless there's nothing else > to interrupt. > > The problem is that if process is waiting for semaphore (and UI > process doing it quite often) > the interrupt handler cannot detect it. Because > 1) it is not scheduled > 2) even if you iterate over Process allInstances and ask #isSuspended > to it, it will answer true > > while 1) is fine, 2) is a design flaw i am talking about: > - there is no way to discriminate between process which waits on > semaphore and suspended process (which has no chances to run unless > you send #resume to it, and therefore no need to interrupt) thanks for the explanation. Stef > >> Cheers, >> Henry >> > > -- > Best regards, > Igor Stasenko. >
