Do threads do anything if main thread ends first?

[Mike Doty]

If MyThread is still executing while PBMAIN is ending, does MyThread do anything?
Is it bad form to not wait for all threads to complete?

#include "win32api.inc"
FUNCTION PBMAIN () AS LONG
  THREAD CREATE MyThread(x???) TO h???
  SLEEP 50
  IF h??? = 0 THEN ? "Error creating thread":EXIT FUNCTION
  REM WaitForSingleObject h???, %INFINITE 
  REM DO:SLEEP 250:LOOP WHILE THREADCOUNT > 1 
  THREAD CLOSE h??? TO result???  'required
END FUNCTION
 
THREAD FUNCTION MyThread(BYVAL x???) AS DWORD
  SLEEP 1000 
  'Does this do anything?
  BEEP 'NO BEEP
  SLEEP 1000
END FUNCTION

[Michael Mattias]

I have often wondered about this myself.

From Doc:

Platform SDK: DLLs, Processes, and Threads

Terminating a Thread

A thread executes until one of the following events occurs:

The thread calls the ExitThread function.
Any thread of the process calls the ExitProcess function.
The thread function returns.
Any thread calls the TerminateThread function with a handle to the thread.
Any thread calls the TerminateProcess function with a handle to the process.

But I can't find anything re when "main" thread ends... or if Windows Automatically calls "ExitProcess"

However, PB imports "ExitProcess" even when I don't call it.... so I can only assume that PB is calling ExitProcess() when it reaches the end of WinMain(). (Why import it if you ain't gonna use it?)

I wrote this:

'ORPHANTHREAD.BAS
' What happens when WinMain ends but a thread fucntion is executing?
' does the thread function end?
' PB/CC 5.0

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
     
   LOCAL hThread AS LONG, Z AS LONG
     
   THREAD CREATE   Worker (0) TO hThread
   
   FOR Z = 1 TO 4
        SLEEP 1000
   NEXT

   STDOUT "Reached end of WinMain"

END FUNCTION


FUNCTION Worker (BYVAL parm AS LONG) AS LONG
     
  LOCAL Z AS LONG, h AS LONG
  
  h = FREEFILE
  OPEN "Orphan.txt" FOR OUTPUT AS h
  
  FOR Z =1 TO 10
       STDOUT USING$ ("Z #", Z)
       PRINT #h, USING$("& Z #", TIME$, Z)
       SLEEP 1000
  NEXT
  CLOSE h
END FUNCTION

I got four lines of output each to the console and the disk file before the program ended and I heard the little sound effect that means 'program ended.'

Best guess is PB calls ExitProcess at end of WinMain... but you'd have to get that confirmed by PB.

Frankly, I think they probably have to do that... or the program ends up at the end of its executable code and has nothing to do... I'd think it probably would generate some type of protection fault in that case.

MCM

[Mike Doty]

I've tried to get threads to do something after main thread completes without success so everything you have said makes sense. I'm still curious if this can cause a memory leak or just isn't good form.

[Michael Mattias]

Any memory leak will clear itself up eventually, but for sure it is poor form.

But you can get your program to wait for your worker thread to complete easily enough (WaitForSingleObject on the thread handle)

[Mike Doty]

I'm incorporating a routine waiting for any file change into a thread.
It will have to be signalled to complete, geez thanks for the extra work.

[Michael Mattias]

Just add an abort object. Win32(SDK): Internet Cookie Monitor April 25, 2001

[Guest]

exitprocess

These are the last two lines executed in every PBMAIN/WINMAIN (applies to pb9 - previous versions not tested, but should be the same)


call ds:CoUninitialize
call ds:ExitProcess



Exiting PBMAIN/WINMAIN terminates the owning process and all its threads.


Guenther

[Michael Mattias]

Well, I guess that settles it. (FINALLY!)

PB calls Exit Process. Windows obeys and terminates all threads of owning process. End.