IPC::Connection multithread support metabug Tracks issues to related to: - send messages from non-main thread - send async reply messages from non-main thread - send messages from multiple threads - send sync messages from multiple threads - send async reply messages from multiple threads - thread safe mutations - thread safe destruction
IPC::Connection already supports sending and receiving IPC off the main thread and we already rely on this extensively. The exception iirc is sync-IPC sending (sendSync) but this likely wouldn't be a lot of work to support. I am not sure where you are going with this.
Yes, I should have been more explicit about the source and target of this bug. In this bug I've linked the problems related to the threading issues explained in the description. There's no strict requirement to solve these yet or product feature to have these. These are more of a collection of issues that I refer to when explaining some problems or when investigating some shortcoming. The idea would be that in this bug, the linked bugs would relate to the use-cases where IPC::Connection would be: - usable from non-main-thread properly and correctly - usable from multiple threads if needed Currently the strategy where the IPC::Connection is mainly bound to main thread and the messages are delivered mainly to main thread is performing worse than needed for the multithreaded use-cases. Currently also most of the claimed thread safe functions seem to not really be thread safe. It's just that the current threading environment doesn't expose the bugs very often and when they are exposed, these seem to be just ignored by the logic of re-running the tests. The issues seem to be for example pure logic issues as well as mechanical thread safety issues. Currently all connections are held in main threads, so the aspect of "usable from non-main-thread properly" is not that critical. The other bug 238516 works towards adding a feature where a connection would be held in non-main thread. I think this is needed for that use-case. I think it would be very worthwhile to consider testing to moving this direction for other cases where the sender or the receiver is mainly in another thread/work queue/run loop. This _should_ simplify the implementation of the threading aspects as well as improve performance. So for example the eventually upcoming offscreen canvas supports would benefit from all: - more thread-safe correct implementation of existing functionality - working thread-safe implementation of sendSync, waitForMessage, sendAsyncWithReply - better delivery of messages to non-main thread by default
<rdar://problem/91305787>