Signal equivalent on Windows #45
Conversation
The conf structs are looped over by-value, so the flag was being set on a copy of the daemon conf struct.
cf. `var signals` in `ztypes_windows.go` in Go's standard library.
|
Hi Duncan. Let me mull this over a bit. I like the approach, and I wonder if there is an argument for making this more general - that is, whether the ability to write to a process's stdin rather than send a signal might be useful in other cases on all platforms. |
|
Something to keep in mind is that it's probably a worthy goal for an identical |
|
In that line of thinking, I can imagine the following as Use a signal: Use a message: Use a signal if the OS supports it, otherwise use a message: |
|
Remove all kits please |
|
Since I'm no longer using Windows for development, I'm not fussed about this mechanism any more |
Hi Aldo. We talked about this briefly a while back in this issue.
To recap...
Windows doesn't support signals. So, the feature of
moddwhereby it can be configured to communicate with daemons by sending signals to them does not work on Windows. The signals silently fail to do anything.(The exception to this is SIGKILL, which the Go runtime recognises the intent of, and uses a native Windows API to directly kill the target process).
I have added a feature I've called "Pipe Signals" to
modd. I've made it so that it can only be enabled on Windows, because there's no need for it on other OSes where normal signals work fine.When Pipe Signals is enabled, daemons are started with a pipe connected to their STDIN. Instead of a signal being sent to the daemon, the textual name of the signal is written as a line on that pipe instead, e.g.
hangup\norinterrupt\n.The daemon process can read its STDIN and take appropriate action. For example, I have also updated
devdto be able to consume hangup in that way to cause a livereload on Windows.Currently the feature is disabled by default (enabled using
modd --pipesignals).What do you think?