Hi, should I work with CreateTread ?
IF I have a big function, can I call it within CreateTread, without waiting, till the function ends ?
does it run paralel ?
Posted on 2003-05-24 07:20:37 by Forginforcer
Yes, it runs in parallel. Invoke like so:
invoke CreateThread, 0, 0, OFFSET MyFunction, 123, 0, ADDR tid

invoke CloseHandle, eax

MyFunction proc lParam:DWORD
; code
MyFunction endp


MyFunction must take one parameter (123 in this case). tid is DWORD value that receives thread identifier. You can discard it if you wish. CreateThread returns handle to thread, but you do not need it, so we CloseHandle() it.
Posted on 2003-05-24 09:28:31 by comrade
hey, thanks, thats seems to be pretty cool !

THX with a big H.u.h.u.!
Posted on 2003-05-24 10:23:25 by Forginforcer
It is possible to close a tread?

DR FF
Posted on 2003-05-25 02:54:00 by Forginforcer
You should read the documentation on threads if your going to use them, imho - it is a small section of the API. Anyhow, let me use the analogy of a music player to explain:

Threads can be suspended (like pause music); threads can be resumed (unpaused song); threads can be exited (like stopping music); threads can be terminated (like closing the music player, or throwing your radio against the wall :)).

Note that ExitThread has to be executed within the thread your exiting, so you'd have to let your thread know to exit, or use TerminateThread from the process.

	invoke ResumeThread, pal.hThread

invoke SuspendThread, pal.hThread

invoke SetThreadPriority, pal.hThread, THREAD_PRIORITY_LOWEST

invoke TerminateThread, pal.hThread, NULL

invoke ExitThread, 0
invoke CloseHandle, pal.hThread ; close handle after exit
Posted on 2003-05-25 08:59:52 by bitRAKE
ah, coool

but than i have to save the tread in a way, or ?
i will look for tread informations, thanks !
Posted on 2003-05-25 12:25:32 by Forginforcer

Yes, it runs in parallel. Invoke like so:
invoke CreateThread, 0, 0, OFFSET MyFunction, 123, 0, ADDR tid

invoke CloseHandle, eax

MyFunction proc lParam:DWORD
; code
MyFunction endp


MyFunction must take one parameter (123 in this case). tid is DWORD value that receives thread identifier. You can discard it if you wish. CreateThread returns handle to thread, but you do not need it, so we CloseHandle() it.


hm.. why are you closing thread handle?
I never did this in my code, is there any possibility for bugs becouse of this?
Posted on 2003-05-25 19:16:44 by Mikky
Hmm, just curious, does CreateRemoteThread work the same as CreateThread, in that the only difference is that it creates a thread in another process?

All the examples i've seen of CreateRemoteThread were adding dlls into processes, which i couldn't understand was to do what...

:stupid:
Posted on 2003-05-25 19:19:30 by Drocon
From the SDK:

Closing a thread handle does not terminate the associated thread. To remove a thread object, you must terminate the thread, then close all handles to the thread.


But I don't know if closing the thread handle before it terminates actually does anything. I would hope that upon termination Windows will immediately release the thread object if the handle is already closed.

I've seen many people do it in their programs, but never have I come accross any documented source that says it's acceptable practice. I'd like to know for sure though.
Posted on 2003-05-26 00:15:24 by iblis
*bump*

It'd be nice to get a definitive answer. ;)
Posted on 2003-05-26 22:16:19 by iblis
The API on TerminateThread (just read it again) doesn't say that the handle is closed - I'm assuming it is like ExitThread, but from outside the thread. I haven't created any threads with a life of their own - more parasitic with the main process thread allocating all the data and creating objects. API says should be careful terminating threads. I'm assuming the thread handle needs to be closed either way. (ExitThread/TerminateThread).
Posted on 2003-05-26 23:59:59 by bitRAKE
This should clear things up
TerminateProcess
Terminating a process causes the following:

1. All object handles opened by the process are closed.

2. All threads in the process terminate their execution. Each thread exits when all its pending I/O has been completed or canceled. The process exits after all its threads exit.

3. The state of the process object becomes signaled, satisfying any threads that had been waiting for the process to terminate. The process object is deleted when the last handle to the process is closed.

4. The states of all threads of the process become signaled, satisfying any threads that had been waiting for the threads to terminate.

5. The termination status of the process changes from STILL_ACTIVE to the exit value of the process.
Windows will close your thread handles to make up for sloppy programming habits, however, all opened handles should be closed, it is just good practice.
Posted on 2003-05-27 00:35:02 by donkey
Just as a PS I tested this by creating 100 threads while watching the handle count in Task Manager, all handles were destroyed on exit.
Posted on 2003-05-27 00:39:25 by donkey
Oh and another BTW:

If you terminate a thread in your process and the process remains open, the system resources for that thread are not freed until it's handle is closed or the process terminates. So you have to close handles if you plan on continuing exectuion of your program or memory leaks will occur.
Posted on 2003-05-27 00:44:50 by donkey
Last note on the subject:
From Multithreading for Rookies
Ruediger R. Asche
Microsoft Developer Network Technology Group


Your application must explicitly close the handle to each object it creates, otherwise it uses up system resources unnecessarily; and the only way to determine when a handle to a thread can be safely closed is to wait for the thread to terminate.
Posted on 2003-05-27 00:59:00 by donkey
BitRAKE and Donkey, thanks, I understand all of this. I know that terminating the thread doesn't close the thread handle. Rather it sets it to a signaled state. And I know that Windows does object cleanup upon process termination for those sloppy programs out there. But I'm referring to closing a thread handle before it terminates.

To illustrate:

[size=12]handle = CreateThread( ... );

// do some processing
// if thread is in a loop, signal it to terminate
// or do nothing if it's not a looping thread
WaitForSingleObject( handle );
CloseHandle( handle );[/size]


That's pseudocode for how I would normally handle threads. Create the thread, wait for it to terminate, then close the handle.

But what some people do, is close the handle immediately after thread creation. The assumption here is that since th handle is already closed before thread termination, the thread object will be freed immediately upon termination, and the main program can go about its business without having to worry about cleanup afterwards.

[size=12]handle = CreateThread( ... );

CloseHandle( handle );[/size]


I've seen many a source code that did this type of thing, but I've never seen any sort of documentation that says that it's okay or good practice to do.
Posted on 2003-05-27 01:12:17 by iblis
iblis, thanks or clarifying - that is a nice trick - think I'll be using it from now on...should thank comrade for posting the code in the first place - he obviously has been using this method.
Posted on 2003-05-27 01:53:11 by bitRAKE
Yeah it's a nice trick, but it is a sanctioned one? That's what I've been asking this whole time.

I've been tempted to do it many times before in my own code, but the only thing stopping me was the question of whether or not it is acceptable programming practice. But I've never seen any MS docs that really talk about it.
Posted on 2003-05-27 06:30:07 by iblis


But what some people do, is close the handle immediately after thread creation. The assumption here is that since th handle is already closed before thread termination, the thread object will be freed immediately upon termination, and the main program can go about its business without having to worry about cleanup afterwards.

[size=12]handle = CreateThread( ... );

CloseHandle( handle );[/size]


I've seen many a source code that did this type of thing, but I've never seen any sort of documentation that says that it's okay or good practice to do.


MSDN

The thread object remains in the system until the thread has terminated Posted on 2003-05-28 23:45:11 by Mecurius
Too vague.

The 'trick' goes against how Windows normally treats object handles. And as such I would think that the trick would get more specific mention in MS docs if it were acceptable practice, but it doesn't.

I've yet to see any guarantees that the method is entirely safe under all circumstances, or any indication that it will continue to be stable in future versions of Windows.

:shrug: Until I find some specific documentation on the issue, I'm going to be on the safe side and manage threads and their handles the old fashioned way.
Posted on 2003-05-29 01:28:35 by iblis