Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling all events in one place #66

Open
kevinburke opened this issue Sep 25, 2018 · 0 comments
Open

Handling all events in one place #66

kevinburke opened this issue Sep 25, 2018 · 0 comments

Comments

@kevinburke
Copy link
Contributor

I had an idea to make it possible to terminate the other subprocesses if one process exits with an error. Right now that's difficult because the events are handled all over the place. I count five different ways that a goreman subprocess can quit:

  • Immediately on cmd.Start() failure, which usually means the command could
    not be found on the PATH, it's not executable, or some other failure starting
    the subprocess.

  • Subprocess decides to exit.

  • Individually stopped by rpc.go.

  • Stopped (and immediately restarted) by rpc.go.

  • By a signal forwarded to the subprocess from the parent, e.g SIGTERM.

These are variously handled in different places across the codebase, which makes inter-process signaling difficult.

Consolidating these into a single place where all incoming events are handled, from different sources:

  • bubbled up from a subprocess
  • incoming signal
  • incoming rpc message

Could simplify the event handling logic. The problem is it would involve a lot of refactoring of the code. I can try to make it as incremental as possible, but it might be difficult.

kevinburke added a commit to kevinburke/goreman that referenced this issue Sep 25, 2018
Structure both incoming signals and the termination of all
subprocesses using incoming channels, which allows us to start working
towards an event loop structure.

Guard all syscall accesses with the corresponding property from the
appropriate x/sys/unix or x/sys/windows package, which provides
better guarantees that the appropriate syscall will be made for the
appropriate GOOS environment.

Updates mattn#66.
kevinburke added a commit to kevinburke/goreman that referenced this issue Sep 25, 2018
Structure both incoming signals and the termination of all
subprocesses using incoming channels, which allows us to start working
towards an event loop structure.

Guard all syscall accesses with the corresponding property from the
appropriate x/sys/unix or x/sys/windows package, which provides
better guarantees that the appropriate syscall will be made for the
appropriate GOOS environment.

Updates mattn#66.
mattn pushed a commit that referenced this issue Sep 26, 2018
Structure both incoming signals and the termination of all
subprocesses using incoming channels, which allows us to start working
towards an event loop structure.

Guard all syscall accesses with the corresponding property from the
appropriate x/sys/unix or x/sys/windows package, which provides
better guarantees that the appropriate syscall will be made for the
appropriate GOOS environment.

Updates #66.
mattn pushed a commit that referenced this issue Sep 26, 2018
Structure both incoming signals and the termination of all
subprocesses using incoming channels, which allows us to start working
towards an event loop structure.

Guard all syscall accesses with the corresponding property from the
appropriate x/sys/unix or x/sys/windows package, which provides
better guarantees that the appropriate syscall will be made for the
appropriate GOOS environment.

Updates #66.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant