Patent Application
20120331469
The present invention is related generally to computer operating systems and, more particularly, to controlling resources in an operating-system environment.
Computing devices are being called upon to run more user applications and to perform more tasks, usually simultaneously, than ever before. To support this increased load, new devices are being built with access to ever greater amounts of internal and external resources (e.g., fast processing, large amounts of internal and external memory, and fast network access).
However, it still occasionally happens that a computing device is called on to perform more work than it can possibly support with its current set of resources. Often, the device knows that a resource shortage is approaching and can take steps to gracefully reduce the amount of work it is doing. When a resource shortage is imminent, the least important processes are told to shut down and to release the resources assigned to them. These released resources are then re-allocated to support more important processes. Given adequate warning, these least important processes can shut down “gracefully,” that is, they can store vital information (usually to long-term memory) so that the work they have been doing can be resumed later without waste. The users of the computing device can also be told of the imminent resource shortage and can take appropriate actions.
The above “graceful” process shutdown is not always possible in current operating-system environments, however. A resource shortage can arise so quickly that the device needs to reclaim resources immediately without taking the time to allow processes to gracefully shut down. For example, some current operating systems run a “low-memory killer” system. Each process running on the device is assigned a special “memory-killing” priority level. When a memory-resource crisis emerges suddenly, the least important processes are “killed” immediately. (They are sent a SIGKILL signal.) Their memory and other resources are released and are re-used to support the more important processes, but the killed processes are not given any time to store their state. Their most recent work cannot be backed up, and the user may be alarmed to see his processes disappear without warning.
When the resource crisis is passed, the killed processes can be restarted, but some of the work they were doing may be lost and must be performed again. Of course, if several recently killed processes are restarted simultaneously and are trying to “catch up,” this can lead to a new resource shortage.
The above considerations, and others, are addressed by the present invention, which can be understood by referring to the specification, drawings, and claims. The present invention introduces the concept of a “buoy” process. The buoy process is a very light-weight process (in most embodiments it does nothing whatsoever) that is associated with another “real” (i.e., non-buoy) process or application. (For purposes of the present discussion, this “real” process is called the “parent” of the buoy, although, in certain embodiments, it is not actually the parent of the buoy process. The possibilities are explained below.) Priorities are arranged so that, in a resource crisis, the buoy process is preferentially killed before its parent. When, during a resource crisis, the buoy is killed, its death is a signal to the parent process that it may be time to shut down gracefully.
In some embodiments, when the parent process starts up, it launches a buoy process as its child. Current operating systems are usually set up to send a signal to a parent process when its child process dies (e.g., a “SIGCHILD” signal). In these embodiments, it is this signal that warns the parent of a resource crisis.
Other embodiments are designed to work even with legacy processes that are unaware of the concept of the buoy process. In these embodiments, a separate “guardian” process is running When the guardian notes the existence of a new “parent” process, the guardian launches a buoy process and associates the buoy with the “parent” process. (Note this terminology: Technically speaking, the actual parent of this buoy is the guardian process, but in the present discussion the process associated with the buoy is called the buoy's parent.) As with the embodiments described above, priorities are set so that during a resource crisis the buoy is killed before its associated parent. When that happens, the operating system informs the guardian, and the guardian in turn informs the associated parent. The parent, again, is given the opportunity to shut down gracefully.
In some embodiments, a single buoy process can be associated with multiple parent processes that should all be shut down together.
Aspects of the present invention are very general and may be implemented to warn of any type of condition. Some example conditions include low-memory, battery-charge level, location proximity, heat level, processor load, availability of a peripheral device, quality of a network connection, and availability of a network connection.
While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable environment. The following description is based on embodiments of the invention and should not be taken as limiting the invention with regard to alternative embodiments that are not explicitly described herein.
The typical user interface of the computing device 100 includes, in addition to the main display 102, a keypad and other user-input devices. The keypad may be physical or virtual, involving virtual keys displayed on a touch screen 102.
At least one operating system 200 occupies some of the memory 108. Also shown are processes 202a, 204, 208a, and 210a. These processes may be of almost any type and could include user applications, support processes, and utility programs.
The two processes 202a and 204a on the left of
Step 304 is optional because it illustrates aspects that are only supported by some operating systems. In this step, each of the parent processes 202a, 204a and each of the buoy processes 202b, 204b is assigned a “memory-killing” priority. The higher its memory-killing priority, the sooner a process will be killed to free up its resources during a memory-resource crisis. In this case, each buoy process 202b, 204b is assigned a higher memory-killing priority than that assigned to its respective parent process 202a, 204a.
A memory-resource crisis emerges in step 306. (As stated above, the methods of the present invention can be applied to conditions other than a memory-resource crisis. Step 304 is altered to fit the condition being protected against.) The operating system frees up resources by killing processes, beginning with those assigned the highest memory-killing priorities. Because of the assignments in step 304 (or their equivalents for other conditions), a buoy process 202b, 204b is killed by the operating system before the operating system gets around to killing the associated parent process 202a, 204a.
When an operating system kills a process, it usually informs the parent of the killed process of that fact (e.g., by sending a SIGCHILD signal). This occurs in step 308. With this warning that a crisis is at hand, the parent processes 202a, 204a may have time, in step 310, to shut down gracefully.
The present invention cannot guarantee that the parent processes 202a, 204a are given enough time in step 310 to complete their graceful shut-downs. The actual result depends upon how quickly the resource crisis develops and how much work the parent processes 202a, 204a need to do during the shut down. At the very least, the parent processes 202a, 204a are warned and begin to save their most critical data.
Note that the method of
However, the method of
The method of
Optional step 404 parallels optional step 304 of
When the resource crisis emerges in step 406, the operating system acts exactly as it did in step 306 of
In some situations, it may be useful to have one buoy process associated with a group of parent processes, if the processes in that group should all be shut down at one time. In some situations, multiple buoy processes (e.g., one for each of several different conditions) can be associated with the same parent process.
In view of the many possible embodiments to which the principles of the present invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. For example, different operating systems implement different methods for launching child processes and for signaling among them. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
