github.com/fvbock/endless

..\github.com\fvbock\endless\endless.go:99: undefined: syscall.SIGUSR1 ..\github.com\fvbock\endless\endless.go:100: undefined: syscall.SIGUSR2 ..\github.com\fvbock\endless\endless.go:103: undefined: syscall.SIGTSTP ..\github.com\fvbock\endless\endless.go:107: undefined: syscall.SIGUSR1 ..\github.com\fvbock\endless\endless.go:108: undefined: syscall.SIGUSR2 ..\github.com\fvbock\endless\endless.go:111: undefined: syscall.SIGTSTP ..\github.com\fvbock\endless\endless.go:193: undefined: syscall.Kill ..\github.com\fvbock\endless\endless.go:243: undefined: syscall.Kill ..\github.com\fvbock\endless\endless.go:288: undefined: syscall.SIGUSR1 ..\github.com\fvbock\endless\endless.go:289: undefined: syscall.SIGUSR2 ..\github.com\fvbock\endless\endless.go:289: too many errors

fvbock commented 9 years ago

syscall being undefined sounds fishy - that's stl...

have you set GOPATH and GOROOT environment variables?

rajeevsikka commented 9 years ago

Yes, GOPATH and GOROOT are both set. Just to be safe I set them in both user and system environment variables.

fvbock commented 9 years ago

hm. which version of go do you run?

stevenh commented 9 years ago

Only standard signals are defined under windows, the more custom ones like SIGUSR1 etc simply don't exist so no this wont work under windows.

fvbock commented 9 years ago

i see. we'd have to use go generate to get a different version compiled on windows i guess? does anybody know how that works?

stevenh commented 9 years ago

Not sure I follow you there @fvbock signals don't really exist on windows.

If you wanted to be portable I would suggest you remove the signal handling from the core of endless replacing with something like a message channel or action messages which the user of endless can implement how they see fit.

This would allow a unix daemons to use signals but a windows service to use service codes for example.

Another benefit of this is that your compatible with existing code which may well already be doing something different with signals.

fvbock commented 9 years ago

@stevenh that's what i meant.

there is stuff like this https://golang.org/src/syscall/syscall_windows.go#L16 - to get different versions depending on what platform you compile. so replacing the signals with something canonical on windows...

i know in general how go generate works but never used it and wonder if somebody has done something like this (platform detect - generate different src - compile) to look at.

stevenh commented 9 years ago

Yer the problem is more that there is no good replacement on windows so it would always need to be implementation specific.

In my head removing signal handling totally and just straight exported methods for:

Shutdown (just export shutdown)
Upgrade (fork from SIGHUP case)
Terminate (just rename hammerTime)

This makes it all much cleaner as the user of endless on unix can decide what signals they want to use and call the relevant methods, no having to hook signals any more.

Does that make sense?

fvbock commented 9 years ago

the canonical way to tell a unix program to shutdown, restart, or terminate is to send it a signal. i don't plan on changing how that is handled in endless.

for the std behaviour you dont have to hook stuff in yourself - endless sets them up. i recently added a function to add hooks without having to do ugly append stuff https://github.com/fvbock/endless/blob/master/endless.go#L541:L559

if windows has a different way of doing signals (and it is not encapsulated in golangs stl/syscall library) it might be nice to use go generate or something similar to get a version that works on windows.

exporting the shutdown(), fork(), etc functions - and the endlessServer itself might be another thing. then develops can choose what they want to do - restart via a signal or with a call if they need it...

stevenh commented 9 years ago

I agree signal handling is the standard way of doing things on unix but each flavour has its own way.

So I guess what I'm saying is allowing endless to be used as a configurable component flexible enough to work how the user wants instead of taking a fixed view provides more options. This is also very idomatic in go, small components that do one job and one job well.

It would be easy to keep the signal handling but as something separate that the user can choose to use if it fits their use case so you end with the best of both worlds. Two separate calls ListenAndServeSignal and ListenAndServeTLSSignal which add the signal support but are contained in a endless_unix.go that has // +build !windows spring to mind as really easy to do.

I'll try knock something up as an example if I get some free time.

fvbock commented 9 years ago

i like the idea of having a choice - i would like to keep ListenAndServe and ListenAndServeTLS - having dropin replacements for the stl is nice...

maybe doing something with env_vars. telling endless whether to start with or without signal handling on... will have to think about it a bit too.

stevenh commented 9 years ago

Here's what I was thinking @fvbock https://github.com/fvbock/endless/pull/19