Sure it's possible, we need to await for the Task if it already exists on the dictionary, for example we could imagine writing something like this inside an actor to make it threadSafe.
private var tasksDictionary: Dictionary<String, Task<Data, Error>>
func getData(at urlString: String) async throws -> Data {
if let currentTask = tasksDictionary[urlString] {
return await currentTask.value
}
let currentTask = Task {
return try await URLSession.shared.data(from: URL(string:urlString)!)
}
tasksDictionary[urlString] = currentTask
let result = await currentTask.value
tasksDictionary[urlString] = nil
return result
}
Hmm, why set `taskDictionary[urlString] = nil` at the bottom there? If the whole point is to cache the result, isn't the point to leave the value there for other requests to pick it up?
Yup, nice catch, no need to reset it to nil if you wanna keep it in memory indefinitely.
I guess making it nil can be also used if you don't wanna make the same request when there is one already in flight, in case you have a 403 error and need to request a refresh token, you don't wanna make two simultaneous requests, but you also don't wanna catch it indefinitely either.
I had this crazy idea a while back using Ray tracing APIs to piggy back a database. Testing for a row could be done shooting in parallel rays to a structure mapped to the data.
You can use examples from any product in any market segment.
The Acorn RISC PC doesn’t count because they don’t make that anymore. It has to be a product on the market today.
I thought the entire point of ARM is that you license the ISA, add in your own special sauce to make your own thing and then sell it as your own thing.
There are ARM architecture systems in the machine room at work. They’re ThunderX2 not “ARM”.
