Correct way to exit a program ?
Re: Correct way to exit a program ?
If you want to be brutal under Linux, you need to call exit(3), or better exit(2)
-
speedfixer
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
Re: Correct way to exit a program ?
I tried exits, various kill PID, PPID methods and more, manually resetting the console on exit by many different methods.
If the threads do all close (usually do, my fault if they don't) a simple 'reset' typed at the console is enough to clear/reset it. Of course, I can't see what I type, but it works. Trying to pipe that command as the last of destructors doesn't work. For example: SCREEN 0 - SLEEP 300, 1 - then a piped 'reset' - still doesn't always work.
It looks like the SCREENCONTROL(200) is the best at the moment. The hints re: flip() and screenset() and screenlock led me to that. Thanks, all.
I don't think the problem is killing the thread(threads) as much as properly resetting the FB I/O buffers states when shutting down graphics.
Perhaps the polling clears more than input buffers and maybe 'unsticks' processes to allow the graphics to properly reset the console.
Someday, I will trace through the code to see the graphics thread closing process to see what really happens. Till then, this isn't a top priority for me. I have something simple now that seems to work.
My 'compile engine' is modded now to know whether graphics would be loaded or not, so the SCREENCONTROL will only be used when needed and the binary can stay 'light.'
david
If the threads do all close (usually do, my fault if they don't) a simple 'reset' typed at the console is enough to clear/reset it. Of course, I can't see what I type, but it works. Trying to pipe that command as the last of destructors doesn't work. For example: SCREEN 0 - SLEEP 300, 1 - then a piped 'reset' - still doesn't always work.
It looks like the SCREENCONTROL(200) is the best at the moment. The hints re: flip() and screenset() and screenlock led me to that. Thanks, all.
I don't think the problem is killing the thread(threads) as much as properly resetting the FB I/O buffers states when shutting down graphics.
Perhaps the polling clears more than input buffers and maybe 'unsticks' processes to allow the graphics to properly reset the console.
Someday, I will trace through the code to see the graphics thread closing process to see what really happens. Till then, this isn't a top priority for me. I have something simple now that seems to work.
My 'compile engine' is modded now to know whether graphics would be loaded or not, so the SCREENCONTROL will only be used when needed and the binary can stay 'light.'
david