Repurposing my questions that weren't a good fit for the group lab to see how that goes :)
I've been building a ScreenReader in Swift leveraging Structured Concurrency, actors, and recently distributed actors over XPC.
https://codeberg.org/SpeakUp
I have a number of questions I could ask (and would love to ask) but would start with asking for thoughts on my RunLoopExecutor project
https://codeberg.org/SpeakUp/RunLoopExecutor/
All of the macOS Accessibility APIs are C/CoreFoundation/CFRunLoop based and I wanted to build something where actors would feel idiomatic for an experienced Swift developer but under the hood we're making sure that we're not contending with ourselves with all the IPC we're doing to get Accessibility data.
I think so far it's been pretty successful as seen in the Controller types for the ScreenReader project: https://codeberg.org/SpeakUp/ScreenReader
I'm currently using pretty naive pool implementations, one that is fixed width and one that is dynamic with a maximum width. Would love to hear different approaches to growing and shrinking the thread pool and handling things like marking a given executor as likely in a bad state (usually meaning the app it's talking to over AX API is blocking it's main thread)
In the AccessibilityElement project https://codeberg.org/SpeakUp/AccessibilityElement for my HIServices Observer implementation I'm exposed to a race condition where axobserver doesn't flush it's notification queue on remove. I'm relying on pthread_specific currently to introduce thread local storage to work around this but it's quite clunky.
In an ideal world the HIServices API would emit a done event to allow cleanup but so far that hasn't happened.
I'll leave it there for now and do new posts with more requests for feedback if this one is well received.