fix: make stdio shutdown more graceful

[jokemanfire]

According to the protocol specifications

Motivation and Context

Make shutdown more graceful.

How Has This Been Tested?

Ut

Breaking Changes

No breaking change

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[jokemanfire]

I'm not sure if adding a shutdown interface is necessary, although it may increase some flexibility for the caller, it may be redundant for the SDK. For me, the previous direct killing behavior was not very elegant, and I would like to hear more opinions.How about you ?
@4t145@alexhancock

[4t145]

I prefer to have a easier approch to cleanup in drop, and give user more flexibility in another explicit method. Or maybe we can just provide an into_inner method so the user can do anything they like with inner process. We can also wrap this wait-and-kill approch into a method, just as @crepererum metioned.

[jokemanfire]

Approve , I will change it.

[jokemanfire]

How about expose the transport in running service? @4t145

[4t145]

@jokemanfire Just have a look on the original issue

1. We can return back the original transport with quit reason. It's not good to put the transport into the RunningService structure, since we already hand over the control of transport into the service worker task, and we can only take it back after task over.
2. We don't have to close the transport in drop, it's a historical issue. The ChildProcess get the transport abilities from AsyncRWTransport, and this transport just return a Ok(()) in close method, where we should implment the closing logic of ChildProcess in. So I think what we need to do is implement Transport trait for it instead of inherit from AsyncRWTransport.
3. By default, we shall follow the recommand approch of official document. But we can still remain some flexibility to user. I think the proper way for user to costomize the closing logic is to create a new type based on current ChildProcess transport and shadow the original closing logic, in other word, inherit and overload.

[jokemanfire]

@4t145@crepererum Have a look , and pls check.

[4t145]

And what's your opinion about give back the ownership of transport after shutdown? Maybe we don't implement this feature in this pr, but it still a point to be discussed.

[jokemanfire]

And what's your opinion about give back the ownership of transport after shutdown? Maybe we don't implement this feature in this pr, but it still a point to be discussed.

If we want to return ownership of the transport, I don't think it should be in the close interface. This can lead to misunderstandings in our understanding of the close interface. I suggest that if necessary, we can set up new interface extensions, and not every transport needs to implement ownership. I have added the into_inner interface for future extensions.

[4t145]

This can lead to misunderstandings in our understanding of the close interface

I mean, return it as serve task's result

maybe change this

pubasyncfnwaiting(self) -> Result<QuitReason, tokio::task::JoinError>

to

pubasyncfnwaiting(self) -> Result<(QuitReason,T), tokio::task::JoinError>

But it will make more difficult to make RunningService a unified type, makes it harder for server management. Just a idea in case of anybody want transport ownership back after service shutdown, in the future.

[crepererum]

Thank you 🙂