“offloading”

FSSupportsKernelOffloadedIO Oh, interesting. This actually came up when I filed a different bug where kernel offloaded IO wasn't working (FB17773100). At first it was closed because I didn't include that key (since it wasn't documented or in the template), but it still didn't work after adding that key until macOS 15.6 beta 3, where it's now fixed. Interesting to see that metadata{Read,Write} is linked to that at the moment. It was indeed the case that adding that key made it work. the FSKit team is working very hard to ship as many fixes as possible in macOS 15 (not just macOS 26) Yeah, I have noticed that the FSKit team has generally been quite responsive and good at updating the statuses of feedbacks I've filed recently. Highly appreciated, by the way! No, or at least not exactly... Interesting insight! I mostly come from a background (or lack thereof) where I kinda just started working with filesystem code first with FUSE as a small thing (for a school project) and found it interesting, then FSKi

hi, i'll offer three suggestions. there's no need (or there may be, but not in this example) for User to be a class. make it a struct and kill the ObservableObject protocol. struct User: Identifiable { let id = UUID() var name: String init(name: String) { self.name = name } } treat the Users object as a viewModel, and when a change is made to a user's name, provide a method for the Users object to do that. class Users: ObservableObject { @Published var users: [User] init() { self.users = [ User(name: John Doe), User(name: Jane Doe) ] } func updateUsername(for user: User, to newName: String) { if let index = users.firstIndex(where: { $0.id == user.id }) { users[index].name = newName } } } and treat the UserDetailView to not be a live edit, but one where you have parameters users and user coming in; you offload the name you want to edit when the view comes on screen; and when you save the edit, ask the Users object to make that change for you. something like this (with the Save button now also dismissi

Hi, @DTS Engineer [quote='820617022, DTS Engineer, /thread/771298?answerId=820617022#820617022'] The queue architecture above handles this. Every queue has an associated dispatch queue, which lets you control parallel packet processing. [/quote] In the RSS feature of Windows (e.g., as described on the website https://learn.microsoft.com/en-us/windows-hardware/drivers/netcx/rsc-offload), the driver developer uses NET_ADAPTER_RECEIVE_SCALING_HASH_SECRET_KEY to request a hash key from the system. This hash key is then used with an algorithm to calculate a hash value, which determines the specific QueueID. Then, I reviewed this document IOUserNetworkRxSubmissionQueue/withpool As I understand it, if I need 4 queues, they can be created using withPool to initialize IOUserNetworkPacketQueueId queueId[0~3]. Each queue extracts packets from the same IOUserNetworkPacketBufferPool, with capacity and bufferCount set as uint32_t capacity, uint32_t bufferCount. However, I am uncertain how to declare or assign valu

So, let me get the bug out of the way first: I reported this as a bug (FB18614667), but also wanted to ask here in case this is actually just me doing There are actually two bugs here: FSSupportsKernelOffloadedIO is the Info.pist key that marks whether or not to use FSVolumeKernelOffloadedIOOperations to shift file I/O into the kernel. We haven't actually documented that key, but there's actually a more general bug on that (r.156162068), which is to consolidate and document all the FSKit's Info.plist keys. That Info.plist key is currently restricting the metadataRead/Write APIs, which it really shouldn't (r.155070316). That is, you should be able to use metadataRead/Write, even if you don't offload I/O. I can't comment on our release schedule, but the fix is straightforward and the FSKit team is working very hard to ship as many fixes as possible in macOS 15 (not just macOS 26). In terms of what you do now: Once #2 is fixed, I believe your code will “just work”. I think it's perfectly reasonable to a

All I need is to check the data on the network every three hours and issue a warning when checking.This isn’t really the intended use case for background fetch. The idea behind background fetch is that the system learns when the user is using the app and, if the user is regularly using it at specific times, the system sends the app a background fetch event before that time so that it can refresh. For example:The user might run a social media app regularly throughout the day, so the system would send that app regular background fetch events.The user might run their news app at breakfast time, so the system would send that app a background fetch event early in the morning.The user might have a second news app on their device but never run it, in which case that app would never get any background fetch events.Background fetch does not guarantee regular background fetch events. Indeed, there is no mechanism on iOS that guarantees regular execution in the background.Once your app has checked the data on the networ

hi, one correction to my last reply: point number (3) wasn't quite right (i had it backwards; sorry, it was the last thing i wrote before heading off to bed). it should have been: (3) instead, if you write something like ExerciceHistoryRow(name: exerciceHistory.name!) and you use var name: String for the View, that will be updated properly. be sure to NOT define this variable using @State, because that gives ownership of the View to SwiftUI. and in general, you'll obviously want to pass along more than just date for a single field in the object ... my conclusions about this whole display not updating situation, especially with Core Data objects (one i've been struggling with for some time): passing a reference to an object to a RowView works fine if it is an @ObservedObject -- and if the RowView makes any changes to the object, you'll know about it. however, deleting that object will crash if the RowView is still held onto by SwiftUI when the deletion occurs. (i think the situation is even more murky when usi

Running large models like Qwen3 1.7B on devices with limited resources, such as the iPhone SE 3 with 4 GB of RAM, is indeed challenging. Let's address your questions and explore potential approaches to mitigate the issues you're facing: Observations and Possible Causes Memory Spike During Load: Dynamic Shape Usage: While dynamic shapes can help manage memory allocation during inference by not preallocating for the full context length, the initial loading process often requires more fixed memory to parse the model, set up internal structures, and potentially convert certain operations to formats supported by the hardware. Intermediate Conversion: Core ML might internally convert some operations from INT4 to INT8 or FP16 if the underlying hardware (BNNS/ANE) doesn't natively support INT4 operations. This can cause temporary spikes in memory usage during loading. Memory Limitations: The iPhone SE 3's 4 GB RAM is quite limited for large models, especially if additional overhead from the operating system and other

@somewhereInTime oh wow, I would've expected the built-in hardware of the Mac Mini to actually work with the shipped OS. Thanks for sharing! I specifically bought a OWC TB3 to 10GbE adapter, as it uses the Aquantia AQC107 chipset. According to the previously shared link to the guide on Github: With the above 5 drivers, currently Apple only uses 2 of them in their products: Aquantia is used on all Macs with 10Gbe ie. 2017 iMac Pro, 2019 Mac Pro, 2018 Mac mini Broadcom is used on all 2011+ Macs with 1Gbe ie. 2011-2020 iMacs, 2010-2020 Mac minis, 2013 Mac Pro However - no luck. Offloading seems to work, the used driver is Driver: com.apple.driver.AppleEthernetAquantiaAqtion. But using ifconfig ether still fails silently :( Upgrading to the latest macOS Sonoma Developer beta seems to have solved my other issue regarding WiFi 6E (6GHz), it now detects my AP correctly and actually connects. But regarding wired network adapters I didn't see any changes. As this is my daily driver I will downgrade to macOS V

Hi again,Thanks for the reply. This makes me aware of a number of risks we did not appreciate.Could I just follow up to be sure I understand them right? Specifically, even after we‘ve switched to CA-signed server certificates, you point out two major reasons we should still avoid performing our own server trust challenge evaluation (or indeed handling any authentication challenge) with background sessions:The first reason is we might be penalized by the iOS resume rate limiter:For background sessions specifically, the resumes necessary to handle this authentication challenge counter against the resume rate limiter.Note This applies to all authentication challenges, not just server trust challenges.My question is, is this an issue even if I'm doing something computationally cheap like checking the certificate's common name? In other words, do you mean that any URLSessionDelegate object which implements urlSession(_ session: didReceive: completionHandler:) is a handicap for background execution, because simply