On Thursday, 30 November 2006 17:04, Rafael J. Wysocki wrote: > On Thursday, 30 November 2006 16:43, Alan Stern wrote: > > On Thu, 30 Nov 2006, Rafael J. Wysocki wrote: > > > > > In fact, I really mean that if we want a process to go to the refrigerator, we > > > have to set PF_FREEZE for it (otherwise try_to_freeze() won't do anytning). > > > Thus because we want stopped processes to go to the refrigerator once they > > > have received the continuation signal, we have to set PF_FREEZE for them, > > > so we should call either freeze_process() or just freeze() for them. > > > > > > Now once we have set PF_FREEZE for a stopped process, we shouldn't count > > > it as freezeable any more, because we can't do anything more with it. > > > Moreover, if the process hasn't received the continuation signal before we > > > call freeze_processes(), PF_FREEZE set will still be set for it, so we have to > > > clear it (otherwise the process would go to the refrigerator as soon as it > > > receives the continuation signal). > > > > I haven't followed the patches, but this obviously is a very tricky issue. > > Yes. > > > A stopped process might be waiting for a signal or event that can be sent > > only by another process which is already frozen -- in which case the > > stopped process is itself effectively frozen without your doing anything > > to it. > > Yes. > > > On the other hand, a stopped process might be waiting for a signal that > > can be sent by an unfreezable process -- and the stopped process might be > > holding a lock which is needed by some other unfreezable process, so you > > need to allow it to run long enough to release the lock before freezing > > it. > > Theoretically, yes. But does it happen? Moreover, even if it does, why can't > we hold the unfreezeable process until the lock is released? > > > Unless you can somehow rule out this scenario (unfreezable process waiting > > for resource held by unfrozen but stopped and freezable process), I don't > > see how this approach can be made to work. Hm, in fact I think that if it happens, then this is a bug. Namely, the freezeable task can only acquire the lock when it's running. Thus it would have to acquire the lock before it's stopped. Consequently, it could be preempted and subsequently frozen after it has acquired the lock and _before_ it's stopped. Now from the unfreezeable task's point of view it doesn't matter if the freezeable task acquired the lock and has been frozen before being stopped or if it acquired the lock and was stopped and then has been woken up and frozen, since in both cases the final outcome is the same: the freezeable task is frozen and holds the lock, so the unfreezeable task cannot continue running. Thus I think the question is if _any_ freezeable task, be it stopped or not, can hold a lock that's needed by an unfreezeable task, and I think the answer is, generally, 'no, it can't', because otherwise it might block the unfreezeable task (if it's frozen while holding the lock). Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller
