Skip to content

Latest commit

 

History

History
84 lines (64 loc) · 5.96 KB

nn-windows-foundation-iclosable.md

File metadata and controls

84 lines (64 loc) · 5.96 KB
UID title description helpviewer_keywords old-location tech.root ms.assetid ms.date ms.keywords req.header req.include-header req.target-type req.target-min-winverclnt req.target-min-winversvr req.kmdf-ver req.umdf-ver req.ddi-compliance req.unicode-ansi req.idl req.max-support req.namespace req.assembly req.type-library req.lib req.dll req.irql targetos req.typenames req.redist ms.custom f1_keywords dev_langs topic_type api_type api_location api_name
NN:windows.foundation.IClosable
IClosable (windows.foundation.h)
Defines a method to release allocated resources.
IClosable
IClosable interface [Windows Runtime]
IClosable interface [Windows Runtime]
described
windows/IClosable
winrt.iclosable
winrt\iclosable.htm
WinRT
856C7D91-15AB-4101-BC5F-232004AD6DF4
12/05/2018
IClosable, IClosable interface [Windows Runtime], IClosable interface [Windows Runtime],described, windows/IClosable, winrt.iclosable
windows.foundation.h
Windows
Windows 8
Windows Server 2012
Windows.Foundation.idl
Windows
19H1
IClosable
windows.foundation/IClosable
c++
APIRef
kbSyntax
COM
Windows.Foundation.h
IClosable

IClosable interface

-description

Defines a method to release allocated resources.

-inheritance

The IClosable interface inherits from the IInspectable interface. IClosable also has these types of members:

-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.