Geeks With Blogs
Greg Young Greg.ToString()

I was recently pushed towards SafeHandles in 2.0 to solve the problems I was having in 1.1. Don't like the idea of porting all my code to 2.0 for a fix but ...

One question I have in my mind as I am a tinkerrer (I refuse to use something unless I understand how it works). (It all seems very similar to handleref or various handleprotecter classes in 1.1 as well)

SafeFileHandle sfhIn = new SafeFileHandle(GetStdHandle(STD_INPUT_HANDLE), false);

this code is functionally equivalent to ..

1 IntPtr foo =GetStdHandle(STD_INPUT_HANDLE);
2 SafeFileHandle sfhIn = new SafeFileHandle(foo, false);

If the thread is aborted do I still not run the risk of having never created a SafeFileHandle object to encapsulate my handle which is only being held in the local?

Also it is important to note that there is also a lighter weight version of safehandle ... criticalhandle which does not perform reference counting.

Useful Resources:

I will be spending quite some time reading up on the reliability contract sections ... quite interesting!

update: makes alot more sense now. I will try to get out and article on some of this stuff in the near future.


Posted on Wednesday, February 22, 2006 4:41 AM | Back to top

Comments on this post: SafeHandle Goodness

# re: SafeHandle Goodness
Requesting Gravatar...
For some reason I cannot post a comment on your blog. Here is what I would have posted:

Both of the code snippets you show are broken. They both allow an Abort to occur and the handle to be leaked. Instead, you need to change the declaration of your PInvokes so they take SafeHandles as arguments and return them directly. Then the PInvoke marshaling layer will ensure that there is no opportunity for an Abort to occur during the conversion to/from the SafeHandle.
Left by Chriss Bumme on Feb 22, 2006 6:18 AM

# re: SafeHandle Goodness
Requesting Gravatar...
Left by Greg Young on Feb 22, 2006 6:19 AM

# re: SafeHandle Goodness
Requesting Gravatar...
FYI, this was all covered in great detail monday night by Jeffrey Richter in his Atlanta visit. In a nutshell, magic pixie dust was sprinkled in the CLR so that as long as you redefine the external import reference to use SafeXxxx rather than an IntPtr, the thread abort will be blocked until the SafeXxx object has been allocated to the managed heap. This same pixie dust also guarantees that the Finalize of any SafeXxx class will be executed - even in a "rude" termination.

I am not sure that explicitly new'ing the SafeHandle object will provide the same CER guarantees.

His slides should be available soon - I strongly recommend downloading them. I think Doug T will most likely post a link on his blog when they are available.

I suspect Jeffrey's new book (supposed to be out yesterday, but BN claims the date is March 22nd) will cover the topic some as well, it is obvious that he is heavily involved in that aspect of CLR design.
Left by Keith Rome on Feb 22, 2006 10:09 PM

# re: SafeHandle Goodness
Requesting Gravatar...
Crap I missed that :(

Need to start sending out email reminders!
Left by Greg Young on Feb 22, 2006 10:13 PM

Your comment:
 (will show your gravatar)

Copyright © Greg Young | Powered by: