|
P: n/a
|
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 this Question
|
P: n/a
|
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 | |
|
P: n/a
|
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
| |
|
P: n/a
|
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 | |
|
P: n/a
|
"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. | |
|
P: n/a
|
"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. | |
|
P: n/a
|
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
| |
|
P: n/a
|
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. | |  Question stats - viewed: 1448
- replies: 7
- date asked: Nov 17 '05
|
