Skip to content
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

NIOSendableBox: allow off-loop initialisation iff Value is Sendable #2753

Merged
merged 2 commits into from
Jun 27, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions Sources/NIOCore/NIOLoopBound.swift
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,26 @@ public final class NIOLoopBoundBox<Value>: @unchecked Sendable {
return .init(_value: nil, uncheckedEventLoop: eventLoop)
}

/// Initialise a ``NIOLoopBoundBox`` by sending a `Sendable` value, validly callable off `eventLoop`.
///
/// Contrary to ``init(_:eventLoop:)``, this method can be called off `eventLoop` because we know that `value` is `Sendable`.
/// So we don't need to protect `value` itself, we just need to protect the ``NIOLoopBoundBox`` against mutations which we do because the ``value``
/// accessors are checking that we're on `eventLoop`.
public static func makeBoxSendingValue(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it weird to use a factory method here personally. I would prefer using an init here. I also see little value in having this constrained to Sendable since Sendable types can freely be shared between threads.

I expected a spelling like this

init(value: sending Value, eventLoop: any EventLoop) {}

This would allow moving an non-Sendable value into an EL's isolation region which is dynamically enforced by the LoopBoundBox.

Copy link
Member Author

@weissi weissi Jun 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • factory is to get "more words", the inits are unconstrained but have to run on eventLoop. And the makeBoxSendingValue ones can be run off the EL with various constraints (either Sendable or sending)
  • sending isn't ready yet (Give NIOLoopBoundBox a sending off-EL initialiser once compiler is ready #2754)
  • there's a huge value for Sendable values. It's not about sending the values around, NIOLoopBoundBox is about mutating the values. Typically this is for thread-safe network clients/servers that have a state machine which only gets accessed on a particular EL. So current: var state: State // only access on self.eventLoop; new: let state: NIOLoopBound<State>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand your goal but IMO NIOLoopBoundBox with an already Sendable value does not make sense. What you want here is just a plain old Box<T> that is conditionally Sendable on T. If the boxed value is already Sendable then the loop enforcement adds no value since the type is already thread safe. The storage might not i.e. the var but the only thing needed for that is to make it a let through adding reference semantics. let boxed = Box<MySendableType> is totally safe.

Copy link
Member Author

@weissi weissi Jun 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not accurate.

  • class Box<T> { var value: T } cannot be Sendable (without synchronisation), you get mutation and sharing.
  • class NIOLoopBoundBox<T> { var value: T /* checks EL on all accesses */ } is always Sendable because it checks that all accesses are on the same EL. So you get mutation but no sharing

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've got no objection to the PR in its current state, but I'm not going to approve because I'd like to see @FranzBusch and @weissi get aligned here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine with taking this as is.

_ value: Value,
as: Value.Type = Value.self,
eventLoop: EventLoop
) -> NIOLoopBoundBox<Value> where Value: Sendable {
// Here, we -- possibly surprisingly -- do not precondition being on the EventLoop. This is okay for a few
// reasons:
// - This function only works with `Sendable` values, so we don't need to worry about somebody
// still holding a reference to this.
// - Because of Swift's Definitive Initialisation (DI), we know that we did write `self._value` before `init`
// returns.
// - The only way to ever write (or read indeed) `self._value` is by proving to be inside the `EventLoop`.
return .init(_value: value, uncheckedEventLoop: eventLoop)
}

/// Access the `value` with the precondition that the code is running on `eventLoop`.
///
/// - note: ``NIOLoopBoundBox`` itself is reference-typed, so any writes will affect anybody sharing this reference.
Expand Down
19 changes: 19 additions & 0 deletions Tests/NIOPosixTests/NIOLoopBoundTests.swift
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,25 @@ final class NIOLoopBoundTests: XCTestCase {
}.wait())
}

func testLoopBoundBoxCanBeInitialisedWithSendableValueOffLoopAndLaterSetToValue() {
let group = MultiThreadedEventLoopGroup(numberOfThreads: 1)
defer {
XCTAssertNoThrow(try group.syncShutdownGracefully())
}

let loop = group.any()

let sendableBox = NIOLoopBoundBox.makeBoxSendingValue(15, as: Int.self, eventLoop: loop)
for _ in 0..<(100 - 15) {
loop.execute {
sendableBox.value += 1
}
}
XCTAssertEqual(100, try loop.submit {
sendableBox.value
}.wait())
}

// MARK: - Helpers
func sendableBlackhole<S: Sendable>(_ sendableThing: S) {}

Expand Down