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. 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. 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. 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. Alan Stern
