|
I am working in managed C++. I have a Mutex object in which I need to
replace the Handle property with a new handle. The new handle is being
constructed using Win32 CreateMutex call. I need to call the Win32 version
in order to set the security descriptor for the mutex, which is not natively
supported in .NET Framework 1.1.
I always get a little nervous about resource leaks when trying to bridge
Win32 with .NET, so I want to make sure there is not the possibility of
calamity here.
The following code is a snippet of one of the managed class methods that I
am using to return a Mutex object with the replaced handle. Will the new
handle be released by the finalizer of the Mutex object, or do I have to do
this manually?
Also, I am not even sure if the code below will work. Can someone verify
please?
static SECURITY_ATTRIBUTES SecAttr;
static SECURITY_DESCRIPTOR SecDesc;
Mutex *Utility::CreateOpenAccessMutex(BOOL InitialyOwn, String *Name, BOOL
*CreatedNew)
{
Mutex *Ret = __gc new Mutex();
HANDLE OldHandle = (HANDLE) Ret->Handle.ToInt32();
CloseHandle(OldHandle);
// Security settings must be explicitly set to allow full access to the
mutex.
InitializeSecurityDescriptor(&SecDesc,SECURITY_DES CRIPTOR_REVISION);
SetSecurityDescriptorDacl(&SecDesc,TRUE,(PACL) NULL,FALSE);
Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name));
if (GetLastError() == ERROR_ALREADY_EXISTS)
{
*CreatedNew = TRUE;
}
else
{
*CreatedNew = FALSE;
}
return Ret;
}
--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
----------------------------------- | |
Share:
|
Ken Varn wrote: I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1.
I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here.
The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually?
Also, I am not even sure if the code below will work. Can someone verify please?
I didn't try it, but looking at the .NET 1.1 source code, it looks like it
ought to be fine. The Handle property of System.Threading.WaitHandle gives
full transparent read/write access to the underlying handle, so when you
assign to the Handle property you're really changing the underlying handle.
You do need to close the old handle value, which you're doing, so I'd say
you're A-OK.
-cd | | |
Well, I tried this out, but something doesn't seem right.
When I assign the Mutex->Handle value to a Win32 HANDLE type, the value of
the Win32 handle is always <undefined> when I look at it in the debugger. I
have even tried type casting it to an INT *, and it comes out as 0. Yet,
when I inspect the Mutex->Handle value, it is a positive number. I don't
understand what is going on here with the IntPtr. Also, when I try to
assign a new value the Matrix->Handle, and I inspect it in the debugger, it
still shows the old value.
I may be getting confused by the behavior of IntPtr and how the debugger
shows the output. Could you please clarify this behavior of IntPtr?
--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
-----------------------------------
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:ej*************@TK2MSFTNGP15.phx.gbl... Ken Varn wrote: I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1.
I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here.
The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually?
Also, I am not even sure if the code below will work. Can someone verify please? I didn't try it, but looking at the .NET 1.1 source code, it looks like it ought to be fine. The Handle property of System.Threading.WaitHandle
gives full transparent read/write access to the underlying handle, so when you assign to the Handle property you're really changing the underlying
handle. You do need to close the old handle value, which you're doing, so I'd say you're A-OK.
-cd | | |
Ken Varn wrote: Well, I tried this out, but something doesn't seem right.
When I assign the Mutex->Handle value to a Win32 HANDLE type, the value of the Win32 handle is always <undefined> when I look at it in the debugger. I have even tried type casting it to an INT *, and it comes out as 0. Yet, when I inspect the Mutex->Handle value, it is a positive number. I don't understand what is going on here with the IntPtr. Also, when I try to assign a new value the Matrix->Handle, and I inspect it in the debugger, it still shows the old value.
I may be getting confused by the behavior of IntPtr and how the debugger shows the output. Could you please clarify this behavior of IntPtr?
There's no light I can shed on the subject really - it sounds like a
debugger bug to me. Perhaps someone else knows.
Other than the oddness in the debugger, does the mutex appear to behave as
you expect?
-cd | | |
"Ken Varn" <nospam> wrote in message
news:ef**************@TK2MSFTNGP12.phx.gbl... I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1.
I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here.
The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually?
Also, I am not even sure if the code below will work. Can someone verify please?
static SECURITY_ATTRIBUTES SecAttr; static SECURITY_DESCRIPTOR SecDesc;
Mutex *Utility::CreateOpenAccessMutex(BOOL InitialyOwn, String *Name, BOOL *CreatedNew) { Mutex *Ret = __gc new Mutex();
HANDLE OldHandle = (HANDLE) Ret->Handle.ToInt32();
CloseHandle(OldHandle);
// Security settings must be explicitly set to allow full access to the mutex. InitializeSecurityDescriptor(&SecDesc,SECURITY_DES CRIPTOR_REVISION); SetSecurityDescriptorDacl(&SecDesc,TRUE,(PACL) NULL,FALSE);
Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name));
if (GetLastError() == ERROR_ALREADY_EXISTS) { *CreatedNew = TRUE; } else { *CreatedNew = FALSE; }
return Ret; }
-- ----------------------------------- Ken Varn Senior Software Engineer Diebold Inc.
EmailID = varnk Domain = Diebold.com -----------------------------------
IMO This:
Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name));
is invalid, you assign a void* to an IntPtr, you have to initialize a new
IntPtr using the void* value returned by CreateMutex like this....
Ret->Handle = IntPtr(CreateMutex(&SecAttr,InitialyOwn, ....
Willy. | | |
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message news:% IMO This: Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name)); is invalid, you assign a void* to an IntPtr, you have to initialize a new IntPtr using the void* value returned by CreateMutex like this....
Ret->Handle = IntPtr(CreateMutex(&SecAttr,InitialyOwn, ....
Willy.
Forget about this, there is an op_explicit(void*) for the IntPtr, so a
simple assignment should work.
Willy. | | |
Well, I did a ToString() call on the Handle and it appears to have been
changed properly. The problem must be with the debugger output when
inspecting pointers. It seems to only want to show the value that the
pointer points to rather than the actual value of the pointer itself. Maybe
this is because of it running in the managed mode.
--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
-----------------------------------
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... Ken Varn wrote: Well, I tried this out, but something doesn't seem right.
When I assign the Mutex->Handle value to a Win32 HANDLE type, the value of the Win32 handle is always <undefined> when I look at it in the debugger. I have even tried type casting it to an INT *, and it comes out as 0. Yet, when I inspect the Mutex->Handle value, it is a positive number. I don't understand what is going on here with the IntPtr. Also, when I try to assign a new value the Matrix->Handle, and I inspect it in the debugger, it still shows the old value.
I may be getting confused by the behavior of IntPtr and how the debugger shows the output. Could you please clarify this behavior of IntPtr?
There's no light I can shed on the subject really - it sounds like a debugger bug to me. Perhaps someone else knows.
Other than the oddness in the debugger, does the mutex appear to behave as you expect?
-cd
| | |
Ken Varn wrote: Well, I did a ToString() call on the Handle and it appears to have been changed properly. The problem must be with the debugger output when inspecting pointers. It seems to only want to show the value that the pointer points to rather than the actual value of the pointer itself. Maybe this is because of it running in the managed mode.
That's probably reasonable. Despite the fact that Handle is defined as
IntPtr, and native HANDLE is defined as void*, it's really just an integer
index into a table - but there's really no way for the debugger to know
that.
-cd | | This discussion thread is closed Replies have been disabled for this discussion. Similar topics
5 posts
views
Thread by Ken Varn |
last post: by
|
1 post
views
Thread by Rocky |
last post: by
|
4 posts
views
Thread by PL |
last post: by
|
2 posts
views
Thread by Ken Durden |
last post: by
|
20 posts
views
Thread by Michael A. Covington |
last post: by
|
1 post
views
Thread by Kris |
last post: by
|
16 posts
views
Thread by Ed Sutton |
last post: by
|
2 posts
views
Thread by Jeroen |
last post: by
| | | | | | | | | | |