_beginthreadex return type and CloseHandle...
Owen Ransen
HANDLE to uintptr_t, (from VC6 to VC2005 I tink)
which is not compatible with CloseHandle, which wants
a HANDLE (naturally)
Can I assume that HANDLE and uintptr_t are compatible in
this case?
I have read and re-read when to use CloseHandle, but I'm
still not sure if I should use it:
>You can call _endthread or _endthreadex explicitly to terminate a
>thread; however, _endthread or _endthreadex is called automatically
>when the thread returns from the routine passed as a parameter.
Ok, I am using _beginthreadex so _endthreadex is called automatically
right?
>Terminating a thread with a call to endthread or _endthreadex
>helps to ensure proper recovery of resources allocated for the
>thread.
Does this mean that in the case of the function hanging I should
call _endthreadex explicitly?
>_endthread automatically closes the thread handle
>(whereas _endthreadex does not). Therefore, when using _beginthread
>and _endthread, do not explicitly close the thread handle
>by calling the Win32 CloseHandle API.
But since I am using _beginthreadex (which calls _endthreadex
automatically) does that mean I should call CloseHandle. And
if so it means I should cast the return value of _beginthreadex
to a HANDLE?
Help!
Easy to use graphics effects:
http://www.ransen.com/
Scott McPhillips [MVP]
news:uc5cp35tite4dvrb8...@4ax.com...
> The return value of _beginthreadex has changed from
> HANDLE to uintptr_t, (from VC6 to VC2005 I tink)
> which is not compatible with CloseHandle, which wants
> a HANDLE (naturally)
>
> Can I assume that HANDLE and uintptr_t are compatible in
> this case?
Yes. A cast may be necessary to pass it to CloseHandle.
> I have read and re-read when to use CloseHandle, but I'm
> still not sure if I should use it:
>
>>You can call _endthread or _endthreadex explicitly to terminate a
>>thread; however, _endthread or _endthreadex is called automatically
>>when the thread returns from the routine passed as a parameter.
> Ok, I am using _beginthreadex so _endthreadex is called automatically
> right?
>
>
>>Terminating a thread with a call to endthread or _endthreadex
>>helps to ensure proper recovery of resources allocated for the
>>thread.
> Does this mean that in the case of the function hanging I should
> call _endthreadex explicitly?
No, but if your thread function hangs there is no 'correct' solution. Don't
do that.
>>_endthread automatically closes the thread handle
>>(whereas _endthreadex does not). Therefore, when using _beginthread
>>and _endthread, do not explicitly close the thread handle
>>by calling the Win32 CloseHandle API.
> But since I am using _beginthreadex (which calls _endthreadex
> automatically) does that mean I should call CloseHandle. And
> if so it means I should cast the return value of _beginthreadex
> to a HANDLE?
Yes, call CloseHandle. In most cases your main thread should wait at
program shutdown until all secondary threads have exited. This lets you
free shared resources safely, after threads have stopped accessing them.
For this reason, _beginthreadex is always preferred, because you want the
thread handle to remain valid after the thread exits so you can pass it to
WaitForMultipleObjects.
--
Scott McPhillips [VC++ MVP]
Owen Ransen
<org-dot-mvps-at-scottmcp> wrote:
>"Owen Ransen" <wi...@wonker.com> wrote in message
>news:uc5cp35tite4dvrb8...@4ax.com...
>> The return value of _beginthreadex has changed from
>> HANDLE to uintptr_t, (from VC6 to VC2005 I tink)
>> which is not compatible with CloseHandle, which wants
>> a HANDLE (naturally)
>>
>> Can I assume that HANDLE and uintptr_t are compatible in
>> this case?
>
>Yes. A cast may be necessary to pass it to CloseHandle.
Thanks.
>> Does this mean that in the case of the function hanging I should
>> call _endthreadex explicitly?
>No, but if your thread function hangs there is no 'correct' solution. Don't
>do that.
I agree with you, but that is what the documents imply.
>Yes, call CloseHandle. In most cases your main thread should wait at
>program shutdown until all secondary threads have exited.
Many thanks!