Experiment with structured process lifecycle management.

[zenhack]

@lthibault, I started playing with my own ideas about how to clean up process lifecycle management. I'm curious to your thoughts, particularly regarding.

• Whether you think the proc package is The Right Abstraction, and whether it will actually help with the rest of the shutdown logic.
• If not, what does goprocess give us that this doesn't?

Part of this is my attempt to understand the problem space.

---

This patch introduces a proc package under internal, with an abstraction I think will be useful in cleaning up the shutdown logic.

It also includes a rework of the send goroutine (in sender.go) that reflects how I want this to work (notably, the logic for drainQueue runs in the send gorotuine itself), and how the proc package can be used to help with that. The new sender is dead code; I intend this as a starting point for discussion.

[zenhack]

Note that this is completely untested (though it compiles), and should not be merged; it's really for discussion only.

[zenhack]

Pushed a tweak; this now also protects some process-specific state, which transfers ownership during shutdown. I think this will be really nice to work with.

[zenhack]

...I wonder if we shouldn't be agressively pulling stuff out of the rpc package and into small, self contained packages under internal/; sender.go is pretty self contained, and it would be nice to have clearer abstraction boundaries within the rpc subsystem.

[lthibault]

I haven't looked at this yet, but I can respond to a couple of points:

Whether you think the proc package is The Right Abstraction, and whether it will actually help with the rest of the shutdown logic. If not, what does goprocess give us that this doesn't?

There's three things I like about goprocess.

1. It provides a clean abstraction for distinguishing between "I am in the process of shutting down" and "I have completely shut down".
2. It provides a clear ordering of goroutine states in a process tree. For example, <-parent.Closing() happens before <-child.Closing().
3. It provides a clear ordering of teardown logic in a process tree. Namely: child.TeardownFunc() happens before parent.TeardownFunc()

I don't have strong feelings about using this library in particular, and I'm very much open to reimplementing some or all of its internally.

...I wonder if we shouldn't be agressively pulling stuff out of the rpc package and into small, self contained packages under internal/; sender.go is pretty self contained, and it would be nice to have clearer abstraction boundaries within the rpc subsystem.

I am very much in favor of this.

[lthibault]

Is this ready for review or are you expecting to do some additional work?

[zenhack]

I should probably test it still, at least.

[lthibault]

@zenhack Is this still planned?

[zenhack]

I still think it's a good idea, it just hasn't made it to the top of my priorities list. Are you blocked on this for something you have in mind, or are you just trying to triage open prs?

[lthibault]

Just triage.

I would like cut an alpha-4 release within the next few weeks, if at all possible, and it would be nice to include this. But no worries if you're swamped.

[zenhack]

Ok. No promises on timeline, but it's not actually api visible anyway (as of this patch, it's actually just dead code).