On Tue, Jan 23, 2018 at 11:20 PM, Sundar Nadathur <ns1.sun...@gmail.com> wrote:
>
> My golang application creates UNIX sockets in specific paths:
> /mypath/name1.sock, /mypath/name2.sock etc. It then launches a go routine
> that listens to one or more of those sockets. I need to ensure that they get
> cleaned up (removed) at the end. I tried the obvious thing -- use defer in
> main() -- and eschewed the use of os.Exit() and log.Fatal(), since they
> don't ensure that defer statements are called.
>
> However, signals like ^C also apparently cause forced termination and don't
> run the defer statements. So, I have experimented with a signal handler
> registered from main(). However, it seems that the ^C is going to the go
> routine that is actually listening on the socket: I don't see the signal
> handler running.
>
> What is a good way to ensure that the resources are always cleaned up even
> in the presence of go routines and signals?

To handle a signal in a Go program, use the os/signal package.  I'm
not sure what you mean when you say that you registered a signal
handler.

That said, the only fully reliable way to do this is to use a separate
wrapper program.  The wrapper program will run the real program, and
then remove the sockets when the real program exits.  That is true in
any language.  There are too many different ways for a program to die,
and there is no way for a program in any language to reliably run code
as it is dying.

Ian

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

Reply via email to