Fix NioAsyncWriter test on concurrency thread pool with single thread

[orobio]

Motivation:

The testSuspendingBufferedYield_whenWriterFinished test fails on the Android emulator. See also the discussion in #3044.

Modifications:

The test requires at least two threads in the concurrency thread pool because it blocks one task, which waits for another task to set a condition. This PR adds support for running a task executor based on a NIOThreadPool and uses it for the test. Using a custom task executor guarantees that at least two threads are available for the test.

Additionally, the test has been renamed to testWriterFinish_AndSuspendBufferedYield, which is more in line with the other test names.

Result:

The test will pass regardless of the width of the global concurrency thread pool.

[orobio]

@finagolfin : Could you verify this fix on the Android emulator?

@Lukasa : I wanted to get some feedback first before writing tests for withNIOThreadPoolTaskExecutor. I will start creating some tests for that function if the fix works, and if this solution is deemed acceptable.

[finagolfin]

Could you verify this fix on the Android emulator?

I can confirm this pull fixes the failing test on the Android emulator, 😃 once I updated the NIO package manifest to add this dependency. Ignore the failing trunk build: a new snapshot was just tagged which requires a three-hour build on my CI, so I manually canceled that trunk build.

The 6.0/6.1 linux runs passed with the emulator set to a single core, meaning this pull fixed that, whereas the mac runs now show other tests failing but this test passes. I don't know what the other mac test failures are about, but I've been seeing a lot of mac flakiness in the last couple hours, so I'm hoping that's a mac CI issue that will go away. 😉

[orobio]

@finagolfin : That is good news. Thank you for verifying! I've added the dependency in Package.swift.

@Lukasa : Would this solution be acceptable? Using NIOThreadPool seemed like the obvious choice, and I designed it to ensure everything is cleaned up by the end of the test. However, incorrect usage could cause withNIOThreadPoolTaskExecutor to wait indefinitely for tasks to finish. I think guaranteed clean-up is a good thing to have for this, but let me know if you'd prefer a different approach.

[Lukasa]

I think in general I'd accept this for this use-case, yeah. Let's just tweak a few things.

[glbrntt]

Thank you!

[FranzBusch]

Sorry for being late to the party but I just realized that this test could be completely re-written to make it work without any thread backed executors and fully reliable. What I wanted to achieve with this test originally was to control the order of the yields and their suspension. I think using a manual task executor would make this test 100 times more maintainable and remove any of the locks.

This is how a manual executor looks like:

import DequeModule
import Synchronization

@available(macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0, *)
final class ManualTaskExecutor: TaskExecutor {
    private let jobs = Mutex<Deque<UnownedJob>>(.init())
    
    func enqueue(_ job: UnownedJob) {
        self.jobs.withLock { $0.append(job) }
    }
    
    func run() {
        while let job = self.jobs.withLock({ $0.popFirst() }) {
            job.runSynchronously(on: self.asUnownedTaskExecutor())
        }
    }
}

With such an executor we should be able to exactly control what child task runs at what point and control when they suspend.

[orobio]

That's an interesting idea. I can have a look at that.

Note that I recently added this test with PR #3044.

[FranzBusch]

Oh sorry. I thought this was one of my original tests. Regardless I think we can achieve the ordering that we want here by manually controlling the order of execution.

[orobio]

@FranzBusch : I pushed an update to switch to a ManualTaskExecutor, which works nicely. Is this what you had in mind?

One note: I have no knowledge of the versions in Apple's ecosystem, so I just copied the @available line from your example, assuming that it is correct.