SR-8572: Rework OperationQueue.isSuspended to stop suspending underly…

[maksimorlovich]

…ing DispatchQueue

• Suspending the underlying DispatchQueue causes issues when an app needs to
  use the same DispatchQueue for scheduling work from multiple OperationQueue's
  and control which OperationQueue's are suspended or not

[maksimorlovich]

@phausler , @dgrove-oss , @parkera , please kindly review. Thanks!

[spevans]

@swift-ci please test

[maksimorlovich]

@bubski @ikesyo @spevans @weissi @dplanitzer @hartbit Could I please get a review for this PR? Thanks!

[parkera]

I'll see if we can get some eyes on this.

[phausler]

Unfortunately this really isnt the way NSOQ works, the current implementation is somewhat close but has some key omissions. there are going to be edge cases for scheduling work here that won't be caught up in the changes listed but it would take probably a much larger effort to get that done than a smaller fix like this.

If I had spare cycles to push it closer to the Darwin implementation this wouldn't really be needed. For now I guess this is an ok bandaid?

[maksimorlovich]

I'm a little confused... Doing some additional testing yesterday, I discovered that the new test case I added running outside the test environment appears to hang. I created a file, queue4.swift with the following content:
`
import Foundation
import Dispatch

var done1 = false
var done2 = false

let dispatchQueue = DispatchQueue(label: "underlying_queue")
let operationQueue = OperationQueue()
operationQueue.maxConcurrentOperationCount = 1
operationQueue.underlyingQueue = dispatchQueue
operationQueue.isSuspended = true

operationQueue.addOperation {
print("here")
done1 = true
}

dispatchQueue.async {
print("there")
operationQueue.isSuspended = false
done2 = true
}

let timeout:TimeInterval = 4
let runLoop = RunLoop.current
let timeoutDate = Date(timeIntervalSinceNow: timeout)
repeat {
if done1 && done2 {
break
}

runLoop.run(until: Date(timeIntervalSinceNow: 0.01))

} while Date().compare(timeoutDate) == ComparisonResult.orderedAscending
`

I compile with with swiftc from 4.2-CONVERGENCE bundle. Then execute it like this:
$> LD_LIBRARY_PATH=/home/morlovich/swift-source/build/Ninja-RelWithDebInfoAssert/foundation-linux-x86_64/Foundation/:/home/morlovich/swift-source/build/Ninja-RelWithDebInfoAssert/xctest-linux-x86_64:/home/morlovich/swift-source/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64/src/.libs: ./queue4

And "here" is never printed. I'm not sure why. This works completely fine in the XCTestCase environment. Any idea what could be wrong? Thanks!

[maksimorlovich]

Nevermind my previous post. I built the full toolchain using swift/utils/build-toolchain from this PR and now everything is fine. I thought it's ok to mix swift-4.2-CONVERGENCE swift compiler with libFoundation I built in debug mode, but that turns out to cause issues. When everything is built together as a single toolchain, everything works fine.

Can we get this merged in please? Thanks!
@spevans @phausler

[parkera]

Thank you @maksimorlovich !

[maksimorlovich]

Thank you @parkera . What is the general process of merging code into master? Will it be done automatically after 4.2 branch is finalized and released? Or are developers themselves responsible for doing the merges? Thanks!

[spevans]

@maksimorlovich Just create another PR against master, normally changes are merged to master first anyway and then ported back to a version branch as needed.

[parkera]

Yes, I missed that this was on the 4.2 branch. I'm going to revert it, actually. Let's do it on master first. Sorry about the process confusion.

[maksimorlovich]

@parkera So that's the process. Master first, then 4.2? (Or whatever the next release branch is, since 4.2 is pretty much done) Thanks!

[maksimorlovich]

Here's the PR for master: #1672
Sorry about the misunderstanding. @parkera @spevans

[parkera]

No worries, I should have noticed the branch.