-
Notifications
You must be signed in to change notification settings - Fork 435
Server handler interceptor state machine #1394
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
Server handler interceptor state machine #1394
Conversation
Motivation: The existing async server handler has a state machine which deals with the interceptor pipeline and the lifecycle of user handler. These are really two separate entities each with its own state machine. This PR is the first in a series which will eventually update the async server handler to make use of the two state machines. Modifications: - Add a 'ServerInterceptorStateMachine' and tests. This acts as a filter for inbound and outbound request and response messages, both as they enter and exit the interceptor pipeline. Message parts delievered in the wrong order lead to the RPC being cancelled, parts delievered after the RPC has finished lead to them being dropped. Cancelling the RPC informs the caller to nil out the associated interceptor pipeline. - Tests - This is not used anywhere (yet). Result: Interceptor state machine is in place.
07eaf9c
to
814de4b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one, LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! A more general question, does the separation of the state machines bring us any closer to having Interceptors on a Channel level or maybe does it make it harder?
No, it has no bearing on that change. |
Motivation: See grpc#1394. Modifications: - Add a 'ServerHandlerStateMachine' and tests. - This is not used anywhere (yet). Result: Handler state machine is in place.
Motivation: See #1394. Modifications: - Add a 'ServerHandlerStateMachine' and tests. - This is not used anywhere (yet). Result: Handler state machine is in place.
Motivation: In grpc#1394 and grpc#1396 we introduced new state machines for the server interceptors and handler. This change updates the async server handler to make use of them. Modifications: - Add the relevant `@inlinable` and `@usableFromInline` annotations to both state machines. - Refactor the async server handler to use both state machines. - Refactor async handler tests to use a 'real' event loop; the previous mix of embedded and async was unsafe. - Re-enable TSAN Result: - Better separation between interceptors and user func - TSAN is happier - Resolves grpc#1362
Motivation: In grpc#1394 and grpc#1396 we introduced new state machines for the server interceptors and handler. This change updates the async server handler to make use of them. Modifications: - Add the relevant `@inlinable` and `@usableFromInline` annotations to both state machines. - Refactor the async server handler to use both state machines. - Refactor async handler tests to use a 'real' event loop; the previous mix of embedded and async was unsafe. - Re-enable TSAN Result: - Better separation between interceptors and user func - TSAN is happier - Resolves grpc#1362
Motivation: In #1394 and #1396 we introduced new state machines for the server interceptors and handler. This change updates the async server handler to make use of them. Modifications: - Add the relevant `@inlinable` and `@usableFromInline` annotations to both state machines. - Refactor the async server handler to use both state machines. - Refactor async handler tests to use a 'real' event loop; the previous mix of embedded and async was unsafe. - Re-enable TSAN Result: - Better separation between interceptors and user func - TSAN is happier - Resolves #1362
Motivation:
The existing async server handler has a state machine which deals with
the interceptor pipeline and the lifecycle of user handler. These are
really two separate entities each with its own state machine.
This PR is the first in a series which will eventually update the async
server handler to make use of the two state machines.
Modifications:
for inbound and outbound request and response messages, both as they
enter and exit the interceptor pipeline. Message parts delievered in the
wrong order lead to the RPC being cancelled, parts delievered after
the RPC has finished lead to them being dropped. Cancelling the RPC
informs the caller to nil out the associated interceptor pipeline.
Result:
Interceptor state machine is in place.