Hi, I open some window using CreateNewProcTags()
and then when quitting main program I use:
is it ok?
Or "better" GetPID() of win/prefs process and then " IDOS->WaitForChildExit(
TiA
There is no point in specifying a particular PID unless that's a feature you actually need.
As long as the parent process created all child processes with NP_Child,TRUE
then DOS knows which child process/es are created by this main parent process.
So, WaitForChildExit(0); is perfectly fine for ANY and ALL child processes
created by the parent, that may still be running, be that none or one or any number.
As long as you call it from the spawning parent process before leaving main() or _start().
Otherwise a child could still be running in freed memory when the main program unloads,
which is never going to end well.
PS: I would enclose those two tests and the signalling calls within Forbid() / Permit() block,
because the pointer check may become invalid in between the test and the Signal() calls.
So Forbid() at line 1 and Permit() at line 9.
THX for explanation. Added Permit/Forbid funcs.
AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonRX550/SSD240GB/DVDRW :-P
@ cwenzel
I thought using Forbid() / Permit() was forbidden or highly advised against on the modern age?
In the past it was used in situations that could be avoided which caused problems.
Stopping multi-tasking should not be taken lightly, but in some cases there is no
other way. For example, there is no global message port locking semaphore
and no way to stop another task running that may be about to zero out a shared
pointer from another task.
Sometimes it is still required, but only when there 's a risk of a multi-threaded
program resource going away at the worst time. (Like the above example).
Of course, it should only be used in these sort of extremely quick operations,
like Signal() and PutMsg() to make sure the pointer doesn't go stale in
the few microseconds between the test and the call.