Remove CreateLinkedTokenSource #408

benaadams · 2015-11-19T21:50:34Z

Resolves #407

Tratcher · 2015-11-19T22:09:06Z

src/Microsoft.AspNet.Server.Kestrel/Http/Frame.cs

@@ -248,8 +245,7 @@ public void Abort()
                        ResponseBody = _responseBody;
                        DuplexStream = new FrameDuplexStream(RequestBody, ResponseBody);

-                        _requestAbortCts = CancellationTokenSource.CreateLinkedTokenSource(_disconnectCts.Token);
-                        RequestAborted = _requestAbortCts.Token;
+                        RequestAborted = _disconnectOrAbortedCts.Token;


I think this is incorrect. RequestAborted needs to be unique per request, not per connection. We don't want registrations from one request to fire for the next request.

Currently the behaviour is after the current request finishes it is Disposed; and if you actually call Abort() it aborts and disconnects?

Will change to maintain that behaviour

After a successful request the token should be disposed without triggering to discard all the registrations.

Actually does it do anything particularly? Its only activated on Abort but that also disconnects

It should activate for disconnects and Abort, and Abort also disconnects. It tells the application to abandon any processing and unwind the middleware chain.

K, might be looking at this wrong. Does the _disconnectCts do anything particularly beyond the _requestAbortCts?

@benaadams It avoids extra synchronization logic that might be required to avoid canceling an already disposed _requestAbortCts when called from places like Connection.Abort().

Turns out that there is still an issue with canceling a disposed _disconnectCts, but at least that isn't being disposed after every request.

Switched it round?

Tratcher · 2015-11-19T23:27:38Z

That might work. @halter73?

benaadams · 2015-11-19T23:37:35Z

Need a CancellationTokenSourceSlim that can have its registrations reset; unfortunately CancellationTokenSource is pretty heavyweight and CancellationToken's constructor is internal and only takes CancellationTokenSource :(

benaadams · 2015-11-19T23:49:54Z

Added https://github.com/dotnet/coreclr/issues/2113

halter73 · 2015-11-20T00:04:31Z

src/Microsoft.AspNet.Server.Kestrel/Http/Frame.cs

@@ -199,12 +199,17 @@ public void Abort()
                ConnectionControl.End(ProduceEndType.SocketDisconnect);
                SocketInput.AbortAwaiting();

-                _disconnectCts.Cancel();
+                _abortedCts?.Cancel();


Maybe wrap this call specifically since we're not locking to avoid ODEs (however unlikely). This prevents us from logging errors that we know can happen but the app developer can do nothing about.

try { _abortedCts.Cancel(); } catch (ObjectDisposedException) { // Don't log ODEs thrown from _abortedCts.Cancel() // If _disconnectCts is disposed, the app has already completed. }

halter73 · 2015-11-20T00:18:21Z

If Connection.Abort was called between requests and an app registered a callback with the RequestAborted token on the next request, the callback would be triggered immediately.

In the end, I don't think this matters since both the request and response are poisoned. Just thought it would be worth mentioning that the behavior changes slightly.

halter73 · 2015-11-20T00:26:16Z

The next request and response streams aren't poisoned I guess, but we still close the socket and poison SocketInput so I still think we're OK.

benaadams · 2015-11-20T00:32:04Z

If Connection.Abort was called between requests and an app registered a callback with the RequestAborted token on the next request, the callback would be triggered immediately.

Isn't that correct because that request if it managed to start would be correctly aborted? Or do you mean it should be receiving a different error?

halter73 · 2015-11-20T00:39:00Z

@benaadams That quote was me trying to describe the old behavior. I don't think the abort callback for the next request will be called after this change.

benaadams · 2015-11-20T00:40:04Z

Ah kk

Avoid allocating the CancellationTokenSource unless it's actually requested. This makes it pay-for-play with regards to code that actually asks for the RequestAborted token and requests that are aborted.

Lazily allocate the RequestAborted CTS

benaadams · 2015-11-21T15:33:31Z

@stephentoub's added changes completely clear up the allocations

halter73 · 2015-11-23T20:03:10Z

src/Microsoft.AspNet.Server.Kestrel/Http/Frame.cs

@@ -146,7 +185,8 @@ public void Reset()

            _prepareRequest?.Invoke(this);

-            _requestAbortCts?.Dispose();
+            _manuallySetRequestAbortToken = null;
+            _abortedCts = null;


Don't we need to to dispose the last _abortedCts (if it exists) to clean up registrations?

/cc @stephentoub

No. CancellationTokenSource.Dispose does a few things:

Disposes of the ManualResetEvent that's lazily-allocated when the WaitHandle is accessed

Disposes of the Timer that's created if the CTS's time-based ctor or its CancelAfter method is used

Disposes of the linked registrations created from a CTS created with CreateLinkedTokenSource

The third one isn't relevant as this CTS isn't being created with CreateLinkedTokenSource.
The second one isn't relevant as we're not using timers.
And while the third one is possibly relevant, it's a) rare that code these days uses CancellationToken.WaitHandle, and b) if it does get lazily-allocated, it'll still get cleaned up via the finalizer.

Given all that, it didn't seem worthwhile to Dispose of it and have to have other code that worried about dispose with the resulting race conditions on its use.

(Dispose also nulls out some fields, but as we're nulling out the reference to the CTS, the whole thing will become eliglble for GC, anyway. The null'ing out is only relevant if the CTS itself is being rooted.)

@stephentoub Thanks for the detailed explanation.

davidfowl · 2015-11-25T06:34:11Z

src/Microsoft.AspNet.Server.Kestrel/Http/Frame.cs

+            {
+                // If a request abort token was previously explicitly set, return it.
+                if (_manuallySetRequestAbortToken.HasValue)
+                    return _manuallySetRequestAbortToken.Value;


nit: style, always use braces

Remove CreateLinkedTokenSource

Remove CreateLinkedTokenSource

58d8c85

Resolves aspnet#407

dnfclas added the cla-already-signed label Nov 19, 2015

Tratcher reviewed Nov 19, 2015
View reviewed changes

Change disconnect to abort cts

3c7431a

halter73 reviewed Nov 20, 2015
View reviewed changes

Don't log ODEs thrown from _abortedCts.Cancel

174ec73

This was referenced Nov 20, 2015

CreateLinkedTokenSource is high alloc #407

Closed

Precomputed header bytes #367

Merged

stephentoub and others added 2 commits November 21, 2015 08:38

Lazily allocate the RequestAborted CTS

c7d7f0e

Avoid allocating the CancellationTokenSource unless it's actually requested. This makes it pay-for-play with regards to code that actually asks for the RequestAborted token and requests that are aborted.

Merge pull request #3 from stephentoub/delay_cts_allocation

16cccb5

Lazily allocate the RequestAborted CTS

halter73 reviewed Nov 23, 2015
View reviewed changes

halter73 mentioned this pull request Nov 23, 2015

RequestAborted cancellation tokens not triggered for Kestrel #30

Closed

benaadams mentioned this pull request Nov 24, 2015

[Testing] Combined Alloc PRs for testing #425

Closed

davidfowl reviewed Nov 25, 2015
View reviewed changes

davidfowl added a commit that referenced this pull request Nov 25, 2015

Merge pull request #408 from benaadams/CancellationTokenSource

ea7f40c

Remove CreateLinkedTokenSource

davidfowl merged commit ea7f40c into aspnet:dev Nov 25, 2015

benaadams deleted the CancellationTokenSource branch May 10, 2016 02:49

Remove CreateLinkedTokenSource #408

Remove CreateLinkedTokenSource #408

Uh oh!

Conversation

benaadams commented Nov 19, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tratcher commented Nov 19, 2015

Uh oh!

benaadams commented Nov 19, 2015

Uh oh!

benaadams commented Nov 19, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

halter73 commented Nov 20, 2015

Uh oh!

halter73 commented Nov 20, 2015

Uh oh!

benaadams commented Nov 20, 2015

Uh oh!

halter73 commented Nov 20, 2015

Uh oh!

benaadams commented Nov 20, 2015

Uh oh!

benaadams commented Nov 21, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!