The MASM Forum Archive 2004 to 2012

General Forums => The Campus => Topic started by: Slugsnack on July 19, 2009, 12:08:45 AM

Title: multithreading
Post by: Slugsnack on July 19, 2009, 12:08:45 AM
anyone have any idea why this multithreading program does not end properly ?

the problem lies in the wm_close case. first i set a boolean to 0 then wait for the other thread to close its own handle. the other thread is waiting for the boolean to be false before doing this so it should work properly. but apparently the code never reaches this point though. at least my message box is never called.

[attachment deleted by admin]
Title: Re: multithreading
Post by: dedndave on July 19, 2009, 12:20:28 AM
could it be no ExitThread or TerminateThread ?
honestly, i was gonna see how you do it, then follow your example - lol
Title: Re: multithreading
Post by: Slugsnack on July 19, 2009, 12:26:45 AM
LOL i'm a poor role model to follow

well ret should be the same as terminating the thread. but the thing is that we know that bit of code is never even hit since the messagebox is not called. i did check the .WHILE condition and what it assembled to and it assembled to a cmp [booleandword], 0 and a jnz so that is correct..

btw if you just wanna do piping well the piping in that example works fine. the program works fine and the exitprocess would close the remaining thread in theory.. but still better practice to do it properly
Title: Re: multithreading
Post by: dedndave on July 19, 2009, 12:32:13 AM
from what i remember, a thread should terminate itself with ExitThread
the calling process may end it with TerminateThread (not as pretty)
i dunno - imma n00b
Title: Re: multithreading
Post by: Slugsnack on July 19, 2009, 12:40:32 AM
when a thread starts its esp is a pointer to a function which calls rtlexituserthread with eax as dwExitCode so that is why ret is basically the same as calling exitthread. and that is why in C before you return from your 'main' you are supposed to set eax to the 0 ( ret 0 ) if your program succeeded

http://msdn.microsoft.com/en-us/library/ms194959(VS.80).aspx
Title: Re: multithreading
Post by: dedndave on July 19, 2009, 12:42:41 AM
lol - that sounds vaguely reminisant of DOS (and CP/M, even - lol)
at offset 0 of the PSP, was an INT 20h, and there was a 0000h on the stack

http://en.wikipedia.org/wiki/CP/M
Title: Re: multithreading
Post by: sinsi on July 19, 2009, 01:21:12 AM
It seems to work OK for me - shows the hops, says "trace complete", tracert.exe disappears from the task manager. Close the window and a msgbox pops up, click OK and your app closes.
If you close your app before tracert.exe finishes, your app hangs but tracert.exe closes itself.
Title: Re: multithreading
Post by: Slugsnack on July 19, 2009, 01:56:41 AM
yeah sorry i didn't make that clear. that is the case that i'm worried about. it shouldn't be hanging
Title: Re: multithreading
Post by: Astro on July 19, 2009, 02:53:34 AM
Hmm... are you sure that instead of hanging, it isn't waiting for the thread to terminate (but now without a UI as you killed it)?

I'm fairly sure you will need to kill your thread before your main app exits.
Title: Re: multithreading
Post by: sinsi on July 19, 2009, 03:30:28 AM
This works as expected(?)

.ELSEIF uMsg == WM_CLOSE
  mov bReadPipe, 0
  invoke TerminateProcess, ProcessInfo.hProcess, NULL
  invoke CloseHandle, ProcessInfo.hProcess
  invoke WaitForSingleObject, hThread, INFINITE
  invoke CloseHandle, hThread
  invoke EndDialog, hwndDlg, NULL

I think you might need a watch on tracert.exe's handle too and kill the thread when it finishes.

edit: maybe you can control tracert.exe from within that thread?
Title: Re: multithreading
Post by: Slugsnack on July 19, 2009, 10:07:47 AM
sinsi :  :clap: :dance: it does work very well now : )

as for tracert.exe's handle, not sure what you mean. after the terminate process call we close the handle to it.