{"id":12953,"date":"2010-09-03T07:00:00","date_gmt":"2010-09-03T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2010\/09\/03\/what-happens-to-a-named-object-when-all-handles-to-it-are-closed\/"},"modified":"2010-09-03T07:00:00","modified_gmt":"2010-09-03T07:00:00","slug":"what-happens-to-a-named-object-when-all-handles-to-it-are-closed","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20100903-00\/?p=12953\/","title":{"rendered":"What happens to a named object when all handles to it are closed?"},"content":{"rendered":"

A customer had a question about named kernel objects:<\/p>\n

I understand that handles in a process if leaked will be destroyed by the kernel when the process exits. My question would be around named objects. <\/p>\n

Would named objects hold their value indefinitely? If I run a small utility app to increment a named counting semaphore, the count of that named semaphore could be lost when that app exits? <\/p>\n

I would expect it to always hold its current value so that transactions across processes and across time could be held even if no process is holding on to it. <\/p>\n<\/blockquote>\n

When the last handle to a named kernel object (such as a named semaphore or a named shared memory block) is closed, the object itself is destroyed. Doesn’t matter whether you explicitly closed the handle by calling CloseHandle<\/code> or the kernel closed the handle for you when it cleaned up the mess you left behind. The object manager doesn’t say, “Well, if the application explicitly called CloseHandle<\/code>, then I’ll also delete the named object, but if the application leaked the handle, then I’ll leave the named object around.”\n First of all, that would kind of belie the whole concept of clean-up. Cleaning up means destroying the resources the application neglected to.\n Second, this would create a bizarre situation where the way to access a new feature is to intentionally do something wrong<\/i>. (Namely, to leak a handle to a named object.)\n Okay, so maybe the expectation was that named objects persisted after all handles to them are closed, even if the handle is closed via the normal CloseHandle<\/code> mechanism. But then how would you delete a named object? There is no DeleteNamedEvent<\/code> function, after all. You could write a process that created 2 billion named objects and then leaked them. Boom, now you can’t clean up by killing the process; you have to restart the computer.\n Kernel objects all follow the same lifetime rules, whether they are named or anonymous: The object is destroyed when the last reference to it is removed (when the handle is closed, noting also that running threads and processes keep a reference to the corresponding kernel object).<\/p>\n

If you want something that survives after all its handles are closed, then use something with a persistence model, like a file. <\/p>\n","protected":false},"excerpt":{"rendered":"

A customer had a question about named kernel objects: I understand that handles in a process if leaked will be destroyed by the kernel when the process exits. My question would be around named objects. Would named objects hold their value indefinitely? If I run a small utility app to increment a named counting semaphore, […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-12953","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

A customer had a question about named kernel objects: I understand that handles in a process if leaked will be destroyed by the kernel when the process exits. My question would be around named objects. Would named objects hold their value indefinitely? If I run a small utility app to increment a named counting semaphore, […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/12953","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=12953"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/12953\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=12953"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=12953"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=12953"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}