'go get' unsupported on Windows

[rajeevsikka]

go get -u github.com/fvbock/endless

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]

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

have you set GOPATH and GOROOT environment variables?

[rajeevsikka]

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

[fvbock]

hm. which version of go do you run?

[stevenh]

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]

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]

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]

@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]

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]

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]

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]

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]

Here's what I was thinking @fvbock #19

[nkev]

@fvbock I need this to work in Windows.
Are the 3 PRs by @stevenh going to merged any time soon?

[orchie]

wow..I have this problem again~
four years so far

[HalfAmazing]

I have this problem again.

go version go1.16.3 windows/amd64

There's a dirty way: https://learnku.com/articles/51696