"Go channels are bad and you should feel bad"

[andrey mirtchovski]

Subject is the title of the article, provided here without comment:

http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/

[Nico]

TL;DR;

* "Channels are slower than implementing it yourself" (i.e. channels are slower than mutexes)
* "it’s actually somewhat challenging to use channels alongside mutexes and condition variables correctly!"
* "Callbacks are strictly more powerful and don’t require unnecessary goroutines."
* "Almost every other operation in Go has a way to avoid a panic (type assertions have the , ok = pattern, for example), but with channels you just get to deal with it."
* "How could channels be better?"

I find interesting the idea of a "comma, ok" pattern for send statements. Is this something the Go authors have considered before?

[Sam Whited]

On Wed, Mar 2, 2016 at 12:29 PM, Nico <nicolas...@gmail.com> wrote:
> I find interesting the idea of a "comma, ok" pattern for send statements. Is this something the Go authors have considered before?

This has been discussed here and on golang-dev.

TL;DR — Senders close channels, receivers check if they're closed. If
you're the sender and you send on a closed channel we panic because
you're doing it wrong; it's effectively an assertion that makes sure
you're using the pattern the way it was intended to be used.

—Sam



--
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

[andrey mirtchovski]

As a counterexample, the Go fork used for the Clive OS allows both
ends of a channel to close and propagates error messages on closing:

http://syssoftware.blogspot.com/2015/06/lsub-go-changes.html

[Marvin Stenger]

One could lift the send statement to be an boolean expression, I guess.

[Nico]

On 02/03/16 18:51, Sam Whited wrote:
> TL;DR — Senders close channels, receivers check if they're closed. If
> you're the sender and you send on a closed channel we panic because
> you're doing it wrong; it's effectively an assertion that makes sure
> you're using the pattern the way it was intended to be used.

What when there are several senders?

An ok-pattern would help synchronise all the senders when the channel is closed by one of them.

[Tapio Raevaara]

I have to admit that I've always wondered why send and receive operations on nil channel don't simply panic. Am I overlooking something obvious here? When is permanent blocking *ever* desirable behaviour in this case?

[Egon]

On Wednesday, 2 March 2016 20:58:36 UTC+2, Nico wrote:

On 02/03/16 18:51, Sam Whited wrote:
> TL;DR — Senders close channels, receivers check if they're closed. If
> you're the sender and you send on a closed channel we panic because
> you're doing it wrong; it's effectively an assertion that makes sure
> you're using the pattern the way it was intended to be used.

What when there are several senders?

Last one sender to leave, turns off the lights, which can be controlled by a atomic int.

[Nathan Fisher]

Out of curiosity what scenario would you see it being good to have multiple publishers to shutdown a channel?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nico]

On 02/03/16 19:08, Egon wrote:
> Last one sender to leave, turns off the lights, which can be controlled by a atomic int.

A.K.A. sync.WaitGroup.

The ok-pattern would make sync.WaitGroup unnecessary in these cases.

[Nico]

On 02/03/16 18:58, Tapio Raevaara wrote:
> I have to admit that I've always wondered why send and receive operations on nil channel don't simply panic. Am I overlooking something obvious here? When is permanent blocking *ever* desirable behaviour in this case?

It's useful within a select.

[Tapio Raevaara]

I don't understand. Doesn't select essentially ignore cases that operate on nil channels anyway? I'm certainly not suggesting that select should panic if one of the channels is nil.

[Sam Whited]

I'm assuming that by "nil" channel you mean one that has nothing in it?

There are lots of use cases for this; in fact, it's an important part
of using channels. For example, you might use this blocking to create
a simple semaphore using channels:

sem := make(chan int, MaxJobs)

func SomeJobHandler(queue chan *Job) {
for job := range queue {
job := job // Copy and shadow request since Go reuses vars
declared in the for statement
sem <- 1// Will block after the buffer is full, eg. when
MaxJobs are running
go func() {
process(job) // Some expensive processing
<-sem
}()
}
}

Of course, this can be handled in other ways, but this is just an example.
Another common example can be found in the time package (the first
case won't be hit until the timeout time has passed):

select {
case <-After(timeout): // This is similar to calling sleep, except
that we can use it in a select statement where we definitely don't
want the read to panic!
return // We've timed out
default:
// Do some work
}

These are just a few simple examples of why we might want to block on
a channel read.

[Tapio Raevaara]

On Wednesday, March 2, 2016 at 10:19:43 PM UTC+2, Sam Whited wrote:

On Wed, Mar 2, 2016 at 12:58 PM, Tapio Raevaara <tapio.r...@iki.fi> wrote:
> I have to admit that I've always wondered why send and receive operations on
> nil channel don't simply panic. Am I overlooking something obvious here?
> When is permanent blocking *ever* desirable behaviour in this case?

I'm assuming that by "nil" channel you mean one that has nothing in it?

No, I mean (chan T(nil)), i.e. a channel that hasn't been initialized. Encountering one is almost certainly a bug, which is why I don't understand why operating on one just silently locks the goroutine instead of panicking. Like I wrote earlier, I don't see how blocking  could ever be desired behaviour in this case.

[Sam Whited]

On Wed, Mar 2, 2016 at 2:18 PM, Sam Whited <s...@samwhited.com> wrote:
> I'm assuming that by "nil" channel you mean one that has nothing in it?

Nevermind, just realized that you meant eg.

var c chan int;

this is different, but still useful.

Eg. imagine you do a select on a nil channel:

func dowork(c chan int) {
select {
case <-c
// Do some work if not nil
default:
return // Don't do anything:
}
}

You don't have to do a nil check on this function, the correct thing
just happens.

—Sam

[Nico]

https://talks.golang.org/2013/advconc.slide#29

[Sam Whited]

On Wed, Mar 2, 2016 at 2:34 PM, Nico <nicolas...@gmail.com> wrote:
> https://talks.golang.org/2013/advconc.slide#29

Exactly, "select never selects a blocking case" is what we're taking
advantage of in the example I sent. If you DO pass in a non-nil
channel, it will be hit, otherwise (if you pass in nil) the default
case will be hit.

—Sam

[Tapio Raevaara]

Why are bringing up select, I'm not suggesting that its semantics should be changed in any way. Select chooses a case where *communication can proceed*, so if an operation on nil channel would panic, select would still ignore those cases, just like it does right now. The following cases are equivalent:

select {
case <-ch:
    break
}

select {
case <-ch:
    break
case <-(chan int(nil)):
}

These would still remain equivalent even if a normal send and receive on a nil channel would panic, because communication on a nil channel cannot proceed.
 
Again, how is it *ever desirable behaviour* that a simple send or receive on a nil channel will just block forever, with no way to recover? Am I missing something here?

[Tapio Raevaara]

On Wednesday, March 2, 2016 at 11:06:00 PM UTC+2, Tapio Raevaara wrote:

select {
case <-ch:
    break
}

select {
case <-ch:
    break
case <-(chan int(nil)):
}

Sorry, that example doesn't make any sense, I'm not sure what strange fumes I was inhaling...

The point is that a case with an operation on a nil channel will never be selected, and that wouldn't change if nil channel operations would panic outside of select. Which is why I don't see how blocking *instead of panicking* on nil channel operation is in any way "useful".

[mikespook]

If you passed a nil chan into the function `dowork`, as far as I can concern:

Yes, the behavior is correct. 

But,

No, the logic is wrong.

The implicit meaning of `case <-c` would cause a big trouble in the feature.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Xing Xing (邢星)
mikespook <mike...@gmail.com>
http://mikespook.com

[Sam Whited]

On Wed, Mar 2, 2016 at 3:14 PM, Tapio Raevaara <tapio.r...@iki.fi> wrote:
> The point is that a case with an operation on a nil channel will never be
> selected, and that wouldn't change if nil channel operations would panic
> outside of select. Which is why I don't see how blocking *instead of
> panicking* on nil channel operation is in any way "useful".

That's not how panic works; panic is for things that should _never_
happen (eg. it's like an assert in other languages). It's a way to
fail fast if something catastrophically bad happens (eg. code that's
impossible to hit is hit because someone screwed something up, a
critical error that could lead to a security compromise happened,
etc.). If something were to panic in a select case, we wouldn't want
it to magically recover the panic and not select that case, we'd still
want to know about it.

You're right, the language could have used panic differently and made
reads from nil channels panic and had select catch them, but it
wouldn't be the same language. This was a deliberate choice to make
things like the example I made possible without magically covering up
serious errors.

TL;DR — I think you're thinking that panic is used for something it
wasn't designed for; blocking is much cleaner.

—Sam

[Nico]

On 02/03/16 21:06, Tapio Raevaara wrote:
> Why are bringing up select?

If send and receive on nil channel didn't block, then the program in https://talks.golang.org/2013/advconc.slide#29 wouldn't work.

> Select chooses a case where *communication can proceed*, so if an operation on nil channel would panic, select would still ignore those cases, just like it does right now.

Just to be clear, a send statement on a closed channel within a select also panics. See:

https://play.golang.org/p/FUbHw_ey8I

package main

func main() {
ch := make(chan struct{})
close(ch)
select {
case ch <- struct{}{}:
default:
}
}

[Alex Bligh]

On 2 Mar 2016, at 21:28, Nico <nicolas...@gmail.com> wrote:

> Just to be clear, a send statement on a closed channel within a select also panics. See:
>
> https://play.golang.org/p/FUbHw_ey8I
>
> package main
>
> func main() {
> ch := make(chan struct{})
> close(ch)
> select {
> case ch <- struct{}{}:
> default:
> }
> }

func main() {
ch := make(chan struct{})
close(ch)
select {

case ch, ok <- struct{}{}:
default:
}
}

The above looks horrible I grant you, but making that return false in ok rather than
panicing would not (I think) break anything. Currently it gives 'select cases cannot be lists'
obviously.

--
Alex Bligh

[Tapio Raevaara]

 Hm... I looked at the spec and I'm wondering *why* that panics. Sending on a closed channel is supposed to panic, but select is only supposed to pick a case where *communication can proceed* (or the default case, of course). Am I misreading the spec somehow?

Oh, and thanks for linking to that program a second time, I totally misread that the first time. Indeed, that program wouldn't work if the semantics were what I'm suggesting, so in a sense the current semantics can be considered "useful". Still, the exact same behaviour would be achieved by wrapping the sends in a select. I maintain that in vast majority of cases trying to operate on a nil channel is *bug* and runtime should panic - like it does if you try to close a nil channel. The fact is that every time you send/receive on a nil channel (without select), you *silently* leak a goroutine.

[Dan Kortschak]

On Wed, 2016-03-02 at 12:29 -0800, Tapio Raevaara wrote:
> No, I mean (chan T(nil)), i.e. a channel that hasn't been
> initialized.
> Encountering one is almost certainly a bug, which is why I don't
> understand why operating on one just silently locks the goroutine
> instead of panicking. Like I wrote earlier, I don't see how blocking
> could ever be desired behaviour in this case.

It can be used to conditionally block a select branch. This is very
useful behaviour.

[Dave Cheney]

Have a look back in the git history to the point when send and receive used to work like this. There is lots of historical discussion, pre go 1.0, that explains why things are the way they are.

[Nico]

On 02/03/16 19:22, Nathan Fisher wrote:
> Out of curiosity what scenario would you see it being good to have multiple publishers to shutdown a channel?

Just out of curiosity:

* here's a fan-in pattern that leaks goroutines: https://play.golang.org/p/oYtXpuOoMJ

* and here, using the currently-invalid "comma, ok" pattern on send statements: https://play.golang.org/p/3MC4JSdJ8t

package main

import "fmt"

func main() {
ch := fanIn(seq(5), seq(10))

for i := range ch {
fmt.Println(i)
if i > 5 {
break
}
}

close(ch) // invalid operation: close(ch) (cannot close receive-only channel)
}

func seq(n int) <-chan int {
ch := make(chan int)
go func() {
for i := 0; i < n; i++ {
// "comma, ok" pattern on send statements
if ch, ok <- i; !ok {
break
}
}
}()
return ch
}

func fanIn(inputs ...<-chan int) <-chan int {
ch := make(chan int)

for _, i := range inputs {
i := i
go func() {
for n := range i {
// "comma, ok" pattern on send statements
if ch, ok <- n; !ok {
close(i) // invalid operation: close(i) (cannot close receive-only channel)
break
}
}
}()
}

return ch
}

[Marvin Stenger]

"comma, ok" pattern on send statements is no option, looks way too odd and ugly.
Making the send statement a boolean expression would be the cleaner way to implement this idea

[Tapio Raevaara]

 I'm talking specifically about send/receive *outside* of select. I though it was obvious that select would ignore those cases anyway, but I guess I should've made that even more obvious. :)

On Thursday, March 3, 2016 at 12:28:37 AM UTC+2, Dave Cheney wrote:

Have a look back in the git history to the point when send and receive used to work like this. There is lots of historical discussion, pre go 1.0, that explains why things are the way they are.

 Communication on nil channel *used* to panic? I've got to admit I've totally forgotten this...! Thanks for pointing this out.

Hm, need to do some digging... I'd still greatly appreciate any links to discussions or examples of the usefulness of the current behaviour.

[Nico]

On 02/03/16 22:42, Marvin Stenger wrote:
> "comma, ok" pattern on send statements is no option, looks way too odd and ugly.
> Making the send statement a boolean expression would be the cleaner way to implement this idea

Yes, I also like it better as a boolean expression:

https://play.golang.org/p/cfRv67pEzJ

package main

import "fmt"

func main() {
ch := fanIn(seq(5), seq(10))

for i := range ch {
fmt.Println(i)
if i > 5 {
break
}
}

close(ch) // invalid operation: close(ch) (cannot close receive-only channel)
}

func seq(n int) <-chan int {
ch := make(chan int)
go func() {
for i := 0; i < n; i++ {

// "comma, ok" pattern on send statements
if ok := ch <- i; !ok {

break
}
}
}()
return ch
}

func fanIn(inputs ...<-chan int) <-chan int {
ch := make(chan int)

for _, i := range inputs {
i := i
go func() {
for n := range i {

// "comma, ok" pattern on send statements
if ok := ch <- n; !ok {

[Nigel Tao]

On Thu, Mar 3, 2016 at 9:42 AM, Tapio Raevaara <tapio.r...@iki.fi> wrote:
> On Thursday, March 3, 2016 at 12:28:37 AM UTC+2, Dave Cheney wrote:
>>
>> Have a look back in the git history to the point when send and receive
>> used to work like this. There is lots of historical discussion, pre go 1.0,
>> that explains why things are the way they are.
>
>
> Communication on nil channel *used* to panic? I've got to admit I've
> totally forgotten this...! Thanks for pointing this out.
>
> Hm, need to do some digging... I'd still greatly appreciate any links to
> discussions or examples of the usefulness of the current behaviour.

It's not so much that it's useful. It's that it's consistent (see e.g.
https://groups.google.com/forum/#!msg/golang-dev/vO9XVbNkC-Q/Hr5qBl7KwgQJ
and https://groups.google.com/forum/#!msg/golang-nuts/WrF9kBDhGEg/pLRYVMByMf0J).

https://groups.google.com/forum/#!msg/golang-dev/VK_L5x1EgBI/0y43UG94qqIJ
says that:

----
For example, given that a select
is defined to wait for one of a collection of cases to be ready
and then execute it, a single-case select:

select {
case xxx:
yyy
}

should, since it is waiting on only a single communication, behave
the same as running the case directly:

{
xxx
yyy
}

Losing that property would, in my opinion, be a serious mistake.
It would make communications behave differently inside select
and outside select, introducing special cases for programmers
to stumble across.

It would be like

switch x {
case y:
...
}

being different from

if x == y {
...
}
----

[Dave Cheney]

Former: The language change happened in r57, back in 2011, https://golang.org/doc/devel/pre_go1.html#r57. The change is spread across multiple commits as it was done in two stages, https://codereview.appspot.com/3973051, incidentally this was the introduction and first use of gofix.

Latter: http://dave.cheney.net/2014/03/19/channel-axioms 

[Nico]

On 02/03/16 23:17, Dave Cheney wrote:
> Former: The language change happened in r57, back in 2011, https://golang.org/doc/devel/pre_go1.html#r57. The change is spread across multiple commits as it was done in two stages, https://codereview.appspot.com/3973051, incidentally this was the introduction and first use of gofix.
>
> Latter: http://dave.cheney.net/2014/03/19/channel-axioms

Dave, thanks for digging this out!

[Christopher Brodt]

It seems like lock contention is a major pain point with channels in Go. What would some potential solutions be? I don't suppose a lock-free implementation is feasible.

[Tapio Raevaara]

I can understand that point of view. Then again, according to the spec, those cases aren't exactly the *same* thing, even if they *behave* the same way right now. In the first case it's the *select* that blocks because no communication can happen, in the second one it's the communication operation itself that blocks... but I guess that difference might be a bit too subtle for some. :)

Nevertheless, I find it really ugly that nil channel ops simply block silently and permanently. Other blocking operations can be recovered from. Panics can be recovered from. Read from a nil channel... that goroutine is forever gone.
 

[Dave Cheney]

On Thursday, 3 March 2016 10:49:59 UTC+11, Christopher Brodt wrote:

It seems like lock contention is a major pain point with channels in Go. What would some potential solutions be? I don't suppose a lock-free implementation is feasible.

This is not true. I encourage you to check out the benchmarks in the runtime package.

[ch...@uberbrodt.net]

Dave, I will take a look at those benchmarks, thanks. I've been led to believe that there's a significant cost to using channels vs mutexes by the OP's article and the following:

http://jmoiron.net/blog/go-performance-tales/

http://bravenewgeek.com/go-is-unapologetically-flawed-heres-why-we-use-it/

Personally, I've not had an issue, though I'm a relatively recent Go programmer.

[Dave Cheney]

Sending data to another goroutine will never be free, there is always some overhead. You should use channels to communicate meaningful amounts of work and consider if two operations are so tightly coupled that one cannot proceed without the other, is your problem actually sequential, rather than concurrent.

[tsuna]

Maybe I’m blind but I didn’t find a clear explanation in any of those
links as to why sending to / receiving from a nil channel (outside a
select) was made to hang forever (and leak the calling goroutine)
rather than crash the program with a panic?

--
Benoit "tsuna" Sigoure

[Devon H. O'Dell]

2016-03-02 16:04 GMT-08:00 Dave Cheney <da...@cheney.net>:
> On Thursday, 3 March 2016 10:49:59 UTC+11, Christopher Brodt wrote:
>>
>> It seems like lock contention is a major pain point with channels in Go.
>> What would some potential solutions be? I don't suppose a lock-free
>> implementation is feasible.
>
> This is not true. I encourage you to check out the benchmarks in the runtime
> package.

Lock-free implementations have been proposed a couple of times for
buffered channels, (design document[1], ML post[2]). This work was
merged[3] (along with work to reduce lock overhead in the channel
implementation[4]), so channel operations are lock-free in some cases.

With unbuffered channels, a lock-free implementation is infeasible.
While it may be possible, the additional latency imposed on
non-contended workloads would severely degrade throughput. The select
statement also complicates matters here.

[1]: https://docs.google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/pub
[2]: https://groups.google.com/forum/#!topic/golang-dev/0IElw_BbTrk
[3]: https://codereview.appspot.com/110580043/
[4]: https://codereview.appspot.com/112990043/

[Jesse McNelis]

On 3 Mar 2016 12:00 p.m., "tsuna" <tsun...@gmail.com> wrote:
>
> Maybe I’m blind but I didn’t find a clear explanation in any of those
> links as to why sending to / receiving from a nil channel (outside a
> select) was made to hang forever (and leak the calling goroutine)
> rather than crash the program with a panic?
>

It's specifically about making the behaviour of channels orthogonal to the select feature. Channel operations act the same whether they are in a select.

The benefit of this is that changes to how channels work don't require special cases in how select works.

Select only cares about whether a channel operation can proceed. New versions of Go can add additional operations to channels and select will still work the same as long as those operations maintain the interface of being able to proceed or not.

[Jason E. Aten]

Review slides 24-27 of John Graham-Cummings presentation at Gohpercon 2014

http://www.slideshare.net/cloudflare/a-channel-compendium

Hint: if you are ever using a channel outside of a select in production code, you are probably doing it wrong. 

You risk deadlock if you try to gracefully shutdown that process.

[Ian Davis]

 

On Thu, Mar 3, 2016, at 07:59 AM, Jason E. Aten wrote:

Review slides 24-27 of John Graham-Cummings presentation at Gohpercon 2014

 

http://www.slideshare.net/cloudflare/a-channel-compendium

 

Hint: if you are ever using a channel outside of a select in production code, you are probably doing it wrong. 

 

You risk deadlock if you try to gracefully shutdown that process.

 

Are you suggesting that ranging over a channel is bad practice?

 

for item := range channel {

 

}

 

 

 

[ch...@uberbrodt.net]

No, because range checks if the channel is closed. Equivalent for/select looks like this:

for {

    select {

        x <- someChan

            //do stuff

        <- someChan

            //channel closed, bail out of for loop

            return

[Ian Davis]

 

On Thu, Mar 3, 2016, at 03:33 PM, ch...@uberbrodt.net wrote:

No, because range checks if the channel is closed. Equivalent for/select looks like this:

 

I agree but I was responding to the suggestion that using channels outside a select block is somehow bad practice.

 

Ian

[Jason E. Aten]

A conditional yes: if you are writing a server process that needs to be able to shut down gracefully, then you should never range over a channel, because it can deadlock the shutdown. All your channel communication needs to be inside a select loop, where one of the options is receiving on the "shutdown request" channel.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/LM648yrPpck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Ian Davis]

On Thu, Mar 3, 2016, at 03:40 PM, Jason E. Aten wrote:

A conditional yes: if you are writing a server process that needs to be able to shut down gracefully, then you should never range over a channel, because it can deadlock the shutdown. All your channel communication needs to be inside a select loop, where one of the options is receiving on the "shutdown request" channel.

 

Forbidding the use of range here seems strange when there are so many other ways to deadlock a server process. It's easy enough to exit a range loop by use of a shared atomic bool or similar. I don't understand these kind of sweeping rules that forbid useful language constructs.

 

Ian

[ch...@uberbrodt.net]

On Thu, Mar 3, 2016, at 03:40 PM, Jason E. Aten wrote:
A conditional yes: if you are writing a server process that needs to be able to shut down gracefully, then you should never range over a channel, because it can deadlock the shutdown. All your channel communication needs to be inside a select loop, where one of the options is receiving on the "shutdown request" channel.

Well, yes, if you never close the channel range will not work for you like you expect. But if your "shutdown request" is closing the channel it should work fine.

Forbidding the use of range here seems strange when there are so many other ways to deadlock a server process. It's easy enough to exit a range loop by use of a shared atomic bool or similar. I don't understand these kind of sweeping rules that forbid useful language constructs.

 I think that using for/select would be more explicit and follow Go conventions, but your proposed approach should work as well.

[Thomas Bushnell, BSG]

You should never write production code which requires a graceful shutdown.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Jakob Borg]

On 03 Mar 2016, at 22:33, ch...@uberbrodt.net wrote:
>
> No, because range checks if the channel is closed. Equivalent for/select looks like this:
>
> for {
> select {
> x <- someChan
> //do stuff
> <- someChan
> //channel closed, bail out of for loop
> return
> }
> }

What sorcery is this? Clearly both receive statements can proceed, so one should be chosen at random, no?

//jb

[ch...@uberbrodt.net]

What sorcery is this? Clearly both receive statements can proceed, so one should be chosen at random, no? 

Ah, you're right, that last case should be a "quitChan" to work properly. Hmm, maybe you do always need a select{}!

[Axel Wagner]

for {

    select {

        case v, ok := <-ch:

            if !ok {

                break

            }

            // ...

[Axel Wagner]

Require -- agreed.

Offer -- strongly disagree.

It is completely fine (and a good thing), if a graceful shutdown can decrease recovering time. In that case an in-production upgrade is simpler and faster but if something crashes you can still recover without a hitch.

[Caleb Spare]

One problem with that is that it's easy for "offered" to become "required" over time as the code changes without anyone noticing, because most shutdowns are clean. Then it crashes and you realize that it's in an unrecoverable state.

[Axel Wagner]

In my (somewhat limited, agreed) experience, processes die for unexpected reasons *all the time*. And if they don't, there's always the chaos monkey to force them to to test those rarely exercised code paths.