Swift 5.3.3 repairs Foundation behavior across platforms

An operation queue can accept concurrent work while its backing dispatch queue prevents that work from running concurrently. That discrepancy is one of the defects repaired in Swift 5.3.3 for Linux and Windows, announced on January 28. The maintenance release changes no application syntax to express the correction. Existing calls reach a different implementation beneath the same Foundation interface.

I like Swift for the way its language design makes ordinary program behavior explicit. Cross-platform libraries have to support that reasoning too. A queue declaration or an optional result helps only when the implementation preserves the behavior that the interface describes. This release contains unusually concrete examples of that dependency.

A concurrent queue needs a concurrent implementation

Alexander Smarus explains the execution defect in the OperationQueue backport. The internally created DispatchQueue lacked the concurrent attribute. The patch adds .concurrent to every branch that constructs that backing queue, including the branches for a supplied name and quality of service. Matching Darwin behavior is the stated aim.

The regression test sets the maximum concurrent operation count to two. Its first operation waits for an expectation that the second operation fulfills. A serial backing queue prevents the second operation from proceeding while the first waits. This is a useful test because completing both operations eventually would not establish concurrent execution. The dependency between their actions makes the missing concurrency observable.

For application code, permitting multiple concurrent operations and implementing the queue that runs them are separate requirements. Raising the operation limit cannot correct a serial dispatch queue underneath it. The repair belongs where Foundation creates that queue, which also means callers do not need a new scheduling API to receive it.

A scheduling pointer could corrupt another list

A separate OperationQueue scheduling fix addresses the links used to track pending operations. The implementation maintains a main operation list and a corresponding priority list. When updating the latter, it assigned the next operation to the main-list link. Smarus identifies the result as crosslinking the lists, with a crash or hang possible during subsequent scheduling.

The entire functional change replaces previous.__nextOperation with previous.__nextPriorityOperation. The small diff conceals a consequential invariant. An operation can participate in more than one ordering, and updating one ordering must preserve the other. A valid reference to an operation is insufficient if it occupies the wrong link in the scheduler.

The added regression test queues an operation with a dependency and then adds another operation. It checks that the dependency runs first and that the expected operations execute. Together with the concurrent-execution test, it distinguishes two failures that an application might otherwise describe simply as a stuck queue. One concerns execution capacity, while the other concerns the integrity of scheduling state.

Container CPU quotas change the meaning of available processors

The ProcessInfo correction makes Linux active processor reporting consult cgroup information. The patch reads a positive CFS quota and period and divides the quota by the period, rounding upward. Its tests include a quota of 150000 with a period of 100000, which yields two. A quota of 50000 with the same period yields one.

When usable quota information is unavailable, the implementation tries the cpuset file. It counts individual processor identifiers and inclusive ranges. If neither source supplies a result, it falls back to the existing CoreFoundation processor query. The source uses specific cgroup file paths, so this is a defined implementation change rather than a claim that every resource-control layout is now understood.

The distinction matters whenever application policy derives worker counts from activeProcessorCount. Such code asks for an integer, but the container restriction may describe a fractional share of CPU time. Upward rounding supplies an integer count without claiming a dedicated physical processor. Choosing a worker count from that result remains an application policy decision. The patch makes the input account for a restriction that the earlier implementation ignored.

An absent calendar result must survive the C boundary

The Calendar.nextDate repair addresses a segmentation fault by changing the nullability of a CoreFoundation callback argument. The C declarations and definition now mark the callback date pointer nullable. On the Swift side, the callback checks for absence, requests that enumeration stop, and returns before converting the value to a Swift object.

Its regression test searches forward from January 1, 2020 for fully specified components in February 2019. With no valid next date, the expected result is nil. The test also includes a successful forward search, so the repair preserves ordinary matching while handling the absent result.

I value optionals because absence belongs in the type system. This patch shows the additional work required when the value crosses a C interface. The declaration must permit a null pointer, and the receiving implementation must handle it before conversion. An optional public result cannot protect a caller from a crash that occurs earlier inside the library.

The release also includes a StreamDelegate accessibility correction. Its protocol extension already supplied an empty stream event handler, but the patch makes that implementation public. External conformers can then use the default implementation. That is another cross-platform behavioral repair achieved without changing the method signature application authors see, and it concerns access control rather than scheduling or pointer validity.