Skip to content

Revert "Fix for a race condition in URLSession (#949)" #1188

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

Merged
merged 1 commit into from
Sep 7, 2017
Merged

Revert "Fix for a race condition in URLSession (#949)" #1188

merged 1 commit into from
Sep 7, 2017

Conversation

weissi
Copy link
Contributor

@weissi weissi commented Aug 24, 2017

This reverts commit 015ded4.

The reason to revert this is that it this pretty certainly works around another bug (SR-5759) and IMHO introduces two new bugs instead.

Dispatch Sources should be cancellable independently. If you have two DispatchSources watching for events on one and the same PR, the should be independent. That was seemingly the problem that was seen here, see the original bug and the discussion in #949.

The two new bugs introduced:

  • a blocking wait self.cancelInProgress?.wait() is introduced when creating a _MultiHandle. Creating a large number of _MultiHandles concurrently could lead to a lot of threads being blocked in the wait. That might exhaust libdispatch's thread pool which might then lead to the cancellation handlers never been fully run
  • CFURLSessionMultiHandleAssign is run on the wrong thread (commandQueue.async )

this should only be merged when SR-5759 is done.

@weissi weissi requested review from pushkarnk and phausler August 24, 2017 10:15
@weissi weissi changed the title Revert "Fix for a race condition in URLSession (#949)" DO NOT MERGE YET (blocked on SR-5759) Revert "Fix for a race condition in URLSession (#949)" Aug 24, 2017
@pushkarnk
Copy link
Member

Looks like swiftlang/swift-corelibs-libdispatch#295 was merged. Let me edit the title first

@pushkarnk pushkarnk changed the title DO NOT MERGE YET (blocked on SR-5759) Revert "Fix for a race condition in URLSession (#949)" Revert "Fix for a race condition in URLSession (#949)" Sep 5, 2017
@pushkarnk
Copy link
Member

pushkarnk commented Sep 6, 2017

I ran the test related to SR-4567 a couple of times and it does pass.

@pushkarnk
Copy link
Member

@MadCoder I took a look at swiftlang/swift-corelibs-libdispatch#295 and have a fundamental question in the context of #949

A DispatchSource.cancel() call returns immediately, the actual EPOLL_CTL_DEL happens asynchronously, and the cancel handler invocation indicates the completion of the cancel operation. The problem in #949 was that after the cancel returned but before the EPOLL_CTL_DEL was executed, if we get EPOLL_CTL_ADD or EPOLL_CTL_MOD requests on the same fd, the latter are missed and we see a hang. Does your PR address this problem?

I did run the test case for #949 only with your fix and it goes through, but just wanted to be sure the problem was actually addressed.

@MadCoder
Copy link

MadCoder commented Sep 6, 2017

Yes, I think my fix addresses this problem

@pushkarnk
Copy link
Member

Thanks @weissi for this great piece of work. As you proved, #949 was vulnerable, because, IMO, fixing a race condition with added synchronisation often creates more race conditions :) I'll go ahead commit this revert.

@pushkarnk
Copy link
Member

@swift-ci please test and merge

@swift-ci swift-ci merged commit 3609b9c into swiftlang:master Sep 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants