IClosable interface (windows.foundation.h)
Defines a method to release allocated resources.
Inheritance
The IClosable interface inherits from the IInspectable interface. IClosable also has these types of members:
Methods
The IClosable interface has these methods.
| IClosable::Close Performs application-defined tasks associated with freeing, releasing, or resetting allocated resources. |
Remarks
Use the IClosable interface to manage the lifetime of system resources, like file handles and network sockets, that are used by a Windows Runtime object.
Some system resources are used exclusively by a single piece of code and must be freed before other code can use them. For example, opening a file for read/write access prevents other code from opening the same file for read/write access, so the code that opened the file must close the file handle before other code can open it.
Other system resources aren't exclusive-use. Many hardware devices, like sensors, geolocation, SMS, and portable devices can be opened multiple times within the same app or by multiple apps.
The IClosable interface enables managing exclusive-use system resources. When you call the Close method on a Windows Runtime object, the object releases its system resources so that they're available for other code to use. Objects that use only shared system resources, like memory and shareable devices, don't implement IClosable.
When you implement the Close method in a Windows Runtime object, your code must release all of the exclusive-use resources that it holds. If the object has references to other closeable Windows Runtime objects, it must call Close on the objects before they're released. Also, your code must release other resources, like references to other Windows Runtime and Component Object Model (COM) objects, and non-exclusive system resources like memory buffers.
Calling the Close method on an object leaves the object in memory, but the object no longer has the system resources that it needs to function properly. Members that depend on released system resources must return RO_E_CLOSED to indicate that the object is closed and that these members no longer work.
Methods defined by the IUnknown and IInspectable interfaces must continue to function normally after Close has been called.
Calling Close on an object that is already closed has no effect and returns S_OK.
Usually, your objects track their closed state by setting a boolean flag when Close is called, or by checking held resources for null or another sentinel value.
Objects don't need to synchronize access to the Close method. This means that race conditions are possible in which one thread calls Close on an object while another thread is using the object. In this case, it's possible to get an error other than RO_E_CLOSED, but you must ensure that the object doesn't cause an access violation.
The Close method doesn't block while waiting for asynchronous operations to complete. So the underlying system resources might not be completely released when the Close method returns. To ensure deterministic closing, the caller must wait for all asynchronous operations to complete or cancel. Objects must complete releasing their system resources as quickly as possible in the face of outstanding asynchronous operations, but must not block while waiting for these to complete.
If your closeable Windows Runtime object exposes an exclusive-use resource to other objects, it must provide a way to affect the ownership semantics of any closeable objects that it holds. For example, the DataReader class provides a DetachStream method that returns the IInputStream that it received when it was created. When DetachStream is called, the DataReader is no longer the owner of the IInputStream, so the DataReader doesn't call Close on the IInputStream.
Requirements
| Requirement | Value |
|---|---|
| Minimum supported client | Windows 8 |
| Minimum supported server | Windows Server 2012 |
| Target Platform | Windows |
| Header | windows.foundation.h |