The NSProcessInfo class provides methods to access information about the current process. Each process has a single, shared NSProcessInfo object, known as process information agent.

The process information agent can return such information as the arguments, environment variables, host name, or process name. The processInfo class method returns the shared agent for the current process—that is, the process whose object sent the message. For example, the following line returns the NSProcessInfo object, which then provides the name of the current process:

NSString*processName=[[NSProcessInfoprocessInfo]processName];

Note

NSProcessInfo is thread-safe in OS X v10.7 and later.

The NSProcessInfo class also includes the operatingSystem method, which returns an enum constant identifying the operating system on which the process is executing.

NSProcessInfo objects attempt to interpret environment variables and command-line arguments in the user's default C string encoding if they cannot be converted to Unicode as UTF-8 strings. If neither conversion works, these values are ignored by the NSProcessInfo object.

Managing Activities

The system has heuristics to improve battery life, performance, and responsiveness of applications for the benefit of the user. You can use the following methods to manage activities that give hints to the system that your application has special requirements:

In response to creating an activity, the system will disable some or all of the heuristics so your application can finish quickly while still providing responsive behavior if the user needs it.

You use activities when your application is performing a long-running operation. If the activity can take different amounts of time (for example, calculating the next move in a chess game), it should use this API. This will ensure correct behavior when the amount of data or the capabilities of the user's computer varies. You should put your activity into one of two major categories:

User initiated: These are finite length activities that the user has explicitly started. Examples include exporting or downloading a user specified file.

Background: These are finite length activities that are part of the normal operation of your application but are not explicitly started by the user. Examples include autosaving, indexing, and automatic downloading of files.

In addition, if your application requires high priority I/O, you can include the NSActivityLatencyCritical flag (using a bitwise OR). You should only use this flag for activities like audio or video recording that really do require high priority.

If your activity takes place synchronously inside an event callback on the main thread, you do not need to use this API.

Be aware that failing to end these activities for an extended period of time can have significant negative impacts to the performance of your user's computer, so be sure to use only the minimum amount of time required. User preferences may override your application’s request.

You can also use this API to control automatic termination or sudden termination (see Sudden Termination). For example:

Because this API returns an object, it may be easier to pair begins and ends than when using the automatic termination API—if the object is deallocated before the endActivity: call, the activity will be automatically ended.

This API also provides a mechanism to disable system-wide idle sleep and display idle sleep. These can have a large impact on the user experience, so be sure not to forget to end activities that disable sleep (including NSActivityUserInitiated).

Sudden Termination

OS X v10.6 and later includes a mechanism that allows the system to log out or shut down more quickly by, whenever possible, killing applications instead of requesting that they quit themselves.

Your application can enable this capability on a global basis and then manually override its availability during actions that could cause data corruption or a poor user experience by allowing sudden termination. Alternately, your application can just manually enable and disable this functionality.

The methods enableSuddenTermination and disableSuddenTermination decrement or increment, respectively, a counter whose value is 1 when the process is first created. When the counter's value is 0 the application is considered to be safely killable and may be killed by the system without any notification or event being sent to the process first.

Your application can support sudden termination upon launch by adding a key to the application’s Info.plist. If the NSSupportsSuddenTermination key exists in the Info.plist and has a value of YEStrue, it is the equivalent of calling enableSuddenTermination during your application launch. This renders the application process killable right away. You can still override this behavior by invoking disableSuddenTermination.

Typically, you disable sudden termination whenever your application defers work that must be done before the application terminates. If, for example, your application defers writing data to disk, and sudden termination is enabled, you should bracket the sensitive operations with a call to disableSuddenTermination, perform the necessary operations, and then send a balancing enableSuddenTermination message.

In agents or daemon executables that don't depend on AppKit you can manually invoke enableSuddenTermination right away. You can then use the enable and disable methods whenever the process has work it must do before it terminates.

NSUserDefaults temporarily disables sudden termination to prevent process killing between the time at which a default has been set and the time at which the preferences file including that default has been written to disk.

NSDocument temporarily disables sudden termination to prevent process killing between the time at which the user has made a change to a document and the time at which the user's change has been written to disk.

Debugging tip

You can determine the value of the sudden termination using the following LLDB command.

Do not attempt to invoke or override suddenTerminationDisablingCount (a private method) in your application. It is there just for this debugging purpose, and may disappear at any time.

Thermal State and App Performance

Use the current thermal state to determine if your app should reduce system usage. On OS X v10.10.3 and later you can register for the NSProcessInfoThermalStateDidChangeNotification to be notified when the thermal state changes. Use thermalState to query the current state. Your app should reduce system usage at higher thermal states. For recommended actions, see NSProcessInfoThermalState.

Declaration

Discussion

The global ID for the process includes the host name, process ID, and a time stamp, which ensures that the ID is unique for the network. This property generates a new string each time its getter is invoked, and it uses a counter to guarantee that strings created from the same process are unique.

Parameters

A string used in debugging to indicate the reason the activity began. This parameter must not be nil or an empty string.

block

A block containing the work to be performed by the activity. The block has no return value and takes the following parameter:

expired

A Boolean indicating whether the process is about to be suspended. If the value is YEStrue, the process is about to be suspended so you should take whatever steps are needed to stop in progress work. If it is NOfalse, start the planned tasks.

Discussion

Use this method to perform tasks when your process is executing in the background. This method queues block for asynchronous execution on a concurrent queue. When your process is in the background, the method tries to take a task assertion to ensure that your block has time to execute. If it is unable to take a task assertion, or if the time allotted for the task assertion expires, the system executes your block with the parameter set to YEStrue. If it is able to take the task assertion, it executes the block and passes NOfalse for the expired parameter.

If your block is still executing and the system need to suspend the process, the system executes your block a second time with the expired parameter set to YEStrue. Your block must be prepared to handle this case. When the expired parameter is YEStrue, stop any in-progress tasks as quickly as possible.