-
Notifications
You must be signed in to change notification settings - Fork 10
Locks on UI thread or async dispatches, can't have neither #5
Comments
Hi @bkase, thanks for your suggestion! How would you proceed in this case? |
From @bkase on April 8, 2016 1:51 I wonder if there exists an easy, clean way to configure the built-in caches to either be threadsafe (use the "AtomicPromise") or fast (use the "MainThreadPromise"). I can imagine there may be something to using protocols to mixin the appropriate promise behavior. protocol Asynchronous {
associatedtype PromiseKind
func makePromise() -> Self.PromiseKind
}
extension Asynchronous where Self.PromiseType == MainThreadPromise {
func makePromise() -> MainThreadPromise {
return MainThreadPromise()
}
}
extension Asynchronous where Self.PromiseType == AtomicPromise {
func makePromise() -> MainThreadPromise {
return AtomicPromise()
}
}
protocol MemoryCacheLevel: CacheLevel, Asynchronous {
/*...*/
}
extension MemoryCacheLevel where Self.KeyType == Hashable {
/* basically all of the current memory cache, but use `makePromise` */
}
class UIMemoryCache<K: Hashable, V/*...*/>: MemoryCacheLevel {
typealias PromiseKind = MainThreadPromise
}
class AtomicMemoryCache: MemoryCacheLevel {
typealias PromiseKind = AtomicPromise
} What do you think about something like this? Also:
Can you do this now? |
Hi @bkase, I'm sorry you're right about the dependency Here comes the catch, though (that is also the reason why I think having two implementations of I have to think about it a little bit more but I'm afraid the complication would be quite big, and adding a "setting" to determine which If you have any other idea, just write it here! |
From @bkase on April 7, 2016 0:6
Due to the use of
ReadWriteLock
s in many places (notablyPromise
s), it's impossible to both avoid touching locks on the MainThread (which is very important esp. if you're using a lot ofPromise
s) and also avoid any async dispatches (which is important when loadingUIImage
s from aMemoryCacheLevel
for example to avoid blinks)One potential solution could be creating two different
Promise
types both conforming to some protocolPromiseType
(and haveFuture
's constructor takePromiseType
rather thanPromise
).where
MainThreadPromise
hasprecondition(NSThread.isMainThread())
everywhere and has no locksAtomicPromise
is currentPromise
with the locks (but acquires locks)Any thoughts?
Copied from original issue: spring-media/Carlos#148
The text was updated successfully, but these errors were encountered: