Can MultiProducerSingleConsumerAsyncChannel.Source be Sendable?

[blindspotbounty]

I would like to use MPSCAsyncChannel as following:

private final class ShardedData: Sendable {
    typealias Channel = MultiProducerSingleConsumerAsyncChannel<Int, Never>
    let shards: UniqueArray<Channel.Source>

    func send(idx: Int, value: Int) async throws {
        try await shards[idx].send(value)
    }
}

Unfortunately Source is mutating on send() and non-sendable itself.
I wonder if that is intentional and if it is safe to workaround it wrapping into @uncheked Sendable class:

private final class ShardedData: Sendable {
    typealias Channel = MultiProducerSingleConsumerAsyncChannel<Int, Never>

    final class SourceWrap: @unchecked Sendable {
        var source: Channel.Source
        init(source: consuming Channel.Source) {
            self.source = source
        }
    }

    let shards: UniqueArray<SourceWrap>

    func send(idx: Int, value: Int) async throws {
        try await shards[idx].source.send(value)
    }
}

or/and as:

    private nonisolated(unsafe) var shards: UniqueArray<Channel.Source>

[FranzBusch]

Yes this is intentional since we are keeping track of the sources to understand if the production is finished. We are using the init and deinit of each source to keep track of how many outstanding sources we have. Furthermore, each source has it's own back pressure tracking so if you start sharing a source then you will hit preconditions and unexpected behavior once back-pressure is exerted. For multi producer patterns you should create a source for each producer.

[blindspotbounty]

@FranzBusch thanks!

Though, can I store it in:

struct ShardData: ~Copyable, Sendable {
    var source: Channel.Source
}

or is there any limitations to send the source itself?

[FranzBusch]

This produces the same problems. It requires an @unchecked Sendable and with this construction you can now share the source with multiple tasks and run into the above mentioned problems. This can easily happen if you store SharedData or even Source in a class Box which automatically becomes Sendable if SharedData is Sendable. This way you can then pass the class between child tasks.

[blindspotbounty]

Hm, I think that it is not possible because it is non-copyable. The worst thing would be to have it let in class and then share.. but then send/finish etc are not possible.
But if we can share ~Copyable across several tasks - something is wrong with thread model itself.

[blindspotbounty]

In other words:

struct Source: Sendable {}
final class C: Sendable {
    var source: Source // `- error: stored property 'source' of 'Sendable'-conforming class 'C' is mutable
}

[FranzBusch]

I am thinking about this more but just to come back to your first example. Even if Source would be Sendable then the example won't work right?

private final class ShardedData: Sendable {
    typealias Channel = MultiProducerSingleConsumerAsyncChannel<Int, Never>
    let shards: UniqueArray<Channel.Source>

    func send(idx: Int, value: Int) async throws {
        try await shards[idx].send(value)
    }
}

You can't mutate a source in a let UniqueArray. You would have to make shards a var which means you can't make SharedData Sendable without an @unchecked Sendable.

[weissi]

Yes this is intentional since we are keeping track of the sources to understand if the production is finished. We are using the init and deinit of each source to keep track of how many outstanding sources we have

This IMHO is the bug in the API of this type. It's a cute trick, but it has ...

• ... really bad API impact -- sources of MPSCs should be Sendable
• ... can lead to bugs -- we're completely hiding the place where finish() is injected by default

Let's please fix this and use the proper tool for this job: Scoped access to sources. withSource { source in ... } where users can manually finish up a source when they're done.

[blindspotbounty]

You can't mutate a source in a let UniqueArray

I agree that this won't work with classes.

However, that prevent me from using it in any Sendable structures and force me to either box it into @unchecked Sendable, either wrap them into Mutex. And I don't like both...
Maybe I missed something about how that should be used but for now I have to workaround it.