Hi, On Wednesday, 6 of April 2005 23:17, Pavel Machek wrote: > Hi! > > > > > I don't think Rafael is suggesting ignoring them. He's suggesting what > > > > I'm already doing: > > > > - Signal so they enter the freezer if they leave the state; > > > > - Don't count them when deciding whether freezing failed; > > > > - Handle the case where they don't leave the state until post resume (I > > > > let them enter the refrigerator, but have code in there to check whether > > > > the freezer is still on). > > > > > > > > In this way, I handle kseriod and anything else uninterruptible without > > > > any problems. > > > > > > What happens if a process owns a lock needed to suspend a device and it is > > > waiting in TASK_UNINTERRUPTIBLE? > > > > Well, we're in trouble. :-) > > > > However, if any process that we have frozen owns such a lock, we're in trouble > > too. > > No, we are not. Processes can't own any locks when they are in > refrigerator... It is not ok to call refrigerator from any context > where you own a lock. I didn't mean a lock in general, but a lock that is needed to suspend a device. If a process holding that lock is frozen, the _suspend() routine for the device won't complete, because it won't be able to get the lock. IOW it will go to sleep and we are single-threaded at that time ... Or am I missing anything? Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland"
