Remove public Shutdown method on WriteHandler.

[bzbarsky-apple]

We don't ever have long-lived WriteHandler instances, so don't need
external shutdown on them.

Fixes #8651

Problem

Exposed method that can be misused.

Change overview

Stop exposing it.

Testing

Code compiles; there were no consumers of this method outside this class.

[msandstedt]

We don't ever have long-lived WriteHandler instances, so don't need
external shutdown on them.

I don't understand this. Write operations take more than zero time (right?), which is why we need the interaction model to asynchronously track their state in the first place. So they will be in-flight for some finite amount of time. How then do these substantively differ from any other type of interaction?

[bzbarsky-apple]

Write operations take more than zero time (right?)

Yes...

which is why we need the interaction model to asynchronously track their state in the first place.

On the sender side. On the receiver side, the WriteHandler is created, WriteHandler::OnWriteRequest is called, and by the time it returns the WriteHandler has been shut down. Nothing async going on there.

If we add async behavior under WriteHandler::OnWriteRequest we will obviously need to change things to accommodate that.

How then do these substantively differ from any other type of interaction?

Read and command interactions currently have the ability for the responding end (CommandHandler/ReadHandler) to do async work before responding. Write interactions do not currently have such an ability: they synchronously respond to the write with a status response.

Again, this is not a feature of the spec, but just of our code. And if we change this we will want to change how the lifetime of WriteHandler is managed in various ways. But right now we could literally be allocating our WriteHandler objects on the stack, and we should strongly consider doing that....

[msandstedt]

Write operations take more than zero time (right?)

Yes...

which is why we need the interaction model to asynchronously track their state in the first place.

On the sender side. On the receiver side, the WriteHandler is created, WriteHandler::OnWriteRequest is called, and by the time it returns the WriteHandler has been shut down. Nothing async going on there.

If we add async behavior under WriteHandler::OnWriteRequest we will obviously need to change things to accommodate that.

How then do these substantively differ from any other type of interaction?

Read and command interactions currently have the ability for the responding end (CommandHandler/ReadHandler) to do async work before responding. Write interactions do not currently have such an ability: they synchronously respond to the write with a status response.

Again, this is not a feature of the spec, but just of our code. And if we change this we will want to change how the lifetime of WriteHandler is managed in various ways. But right now we could literally be allocating our WriteHandler objects on the stack, and we should strongly consider doing that....

OK, this answers my other question about whether writes are sync. Yes they are, and this approach relies on that.

Also agree that we ought to just being doing this on the stack.