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. Well, currently we're treating all stopped processes as non-freezeable. This also is theoretically wrong, because, for example, the continuation signal may be delivered to a stopped userland proces after we have frozen all of the other userland processes, so we won't be freezing this one and it'll be allowed to run when we are saving the image, which is generally dangerous. I also haven't seen it happening, though. Thus there are two theoretical issues on the table, but I think the probability of the second one actually happening is a bit greater. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller
