I am using SDL running on a Raspberry Pi for a embedded product I am developing. The RPi has a wireless adapter so all interaction is via SSH from my MAC. NOTE: I am NOT redirecting the app’s output to my MAC via X; the RPi has its own dedicated HDMI display.
I can remotely start the application by executing the app via sudo. However I’ve not found a way to cleanly terminate the app via SSH. If I kill the process, SDL is left in an undefined state and I have to reboot to run my app again.
Is there a clean way to terminate my SDL app remotely?
Is there a clean way to terminate my SDL app remotely?
I don’t understand how this is any different from any other
termination. You should get an SDL_Quit event and respond
to it, no?On 26/06/2013, at 4:45 AM, craiglindley wrote:
Quoth craiglindley , on 2013-06-25 15:38:50 -0700:
How exactly do I generate the QUIT event from an remote computer ?
Do a kill of the apps process doesn’t seem to generate one.
Unless you initialized SDL without the signal handlers
(SDL_INIT_NOPARACHUTE in 1.2, I believe), SIGINT and SIGTERM should
both be caught and translated to SDL_QUIT events; the former
corresponds to the terminal interrupt key, and the latter is the
default for the ‘kill’ shell command if you don’t specify a signal.
So that should work. What exactly are you using to signal the
process?
SIGQUIT usually means to exit with less cleanup and/or to exit with
a core dump. SDL doesn’t catch those anywhere I’m aware of. That
suggests that your restart mechanism might be working only when you don’t let SDL catch the signal, which suggests something else is
wrong.
As far as john skaller’s idea, terminal-based job control causes
SIGHUP to be delivered when a controlling terminal goes away, usually
destroying all processes that you started from that connection that
didn’t explicitly background themselves. SDL doesn’t catch these on
any platform I’m aware of.
Quoth Drake Wilson <@Drake_Wilson>, on 2013-06-25 22:22:05 -0500:
SIGQUIT usually means to exit with less cleanup and/or to exit with
a core dump. SDL doesn’t catch those anywhere I’m aware of.
[…]
As far as john skaller’s idea, terminal-based job control causes
SIGHUP to be delivered when a controlling terminal goes away, usually
destroying all processes that you started from that connection that
didn’t explicitly background themselves. SDL doesn’t catch these
Gyaaah, no, I got it mixed up with another system. SIGQUIT is
actually caught by the “parachute” mechanism, SIGINT and SIGTERM are
caught by the quit mechanism, and grepping the source it looks like
the X backend specifically catches SIGHUP in 1.2, though not in 2.0,
for reasons that have not been explained.
Not that that makes that much difference to the original situation,
in which my curiosity would be why plain SIGINT/SIGTERM isn’t working
to begin with.
(Must—stop—being tempted to send mail before breakfast—!)
As far as john skaller’s idea, terminal-based job control causes
SIGHUP to be delivered when a controlling terminal goes away, usually
destroying all processes that you started from that connection that
didn’t explicitly background themselves. SDL doesn’t catch these on
any platform I’m aware of.
Ah, of course. Thanks for refreshing my memory. So a custom signal
handler could fix this by posting SDL_Quit event?On 26/06/2013, at 1:22 PM, Drake Wilson wrote: