I just did a quick test, and "kill <pid>" will stop the Racket web server, 
but not gracefully. In other words, it doesn't allow the current request to 
finish. Maybe another signal will gracefully stop it?

On Friday, November 30, 2018 at 1:36:04 PM UTC-5, Brian Adkins wrote:
>
> The Unicorn app server uses signals to perform a graceful restart of the 
> worker processes. For example: "kill -USR2 <pid>". This seems like a 
> reasonable approach, so my first though was to use something similar for my 
> Racket app server processes.
>
> I found Tony's unix-signals package, but the introduction states, "Be 
> warned that attempting to receive certain signals used by the Racket 
> runtime is dangerous, as the code here will conflict with the code in 
> Racket itself." I'm guessing this does not apply to SIGUSR2. I guess the 
> idea would be to start a thread & block on (read-signal).
>
> Are there alternatives I should consider for this functionality? Given the 
> Racket app server processes are listening for HTTP requests, I could use 
> HTTP to accomplish this. The Racket app server processes are not exposed to 
> the internet, from the internet, they're only accessible via nginx.
>
> Can I use signals and handle them via Racket's exception mechanism? For 
> example, will "kill -HUP <pid>" result in an exn:break:hang-up exception 
> being raised?
>
> Thanks,
> Brian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to