Dead lock

[cherpake]

Dead lock when using - (BOOL)diskImageExistsForURL:(NSURL *)url; to check if image exists on the disc.

As it's calling:

• (BOOL)diskImageExistsWithKey:(NSString *)key
  {
  __block BOOL exists = NO;
  //
  // DEAD LOCK HERE
  //
  dispatch_sync(_ioQueue, ^
  {
  exists = [_fileManager fileExistsAtPath:[self defaultCachePathForKey:key]];
  });

  return exists;
  }

and another thread is waiting on:

        dispatch_main_sync_safe(^
        {
            doneBlock(diskImage, SDImageCacheTypeDisk);
        });

in this method: - (NSOperation *)queryDiskCacheForKey:(NSString *)key done:(void (^)(UIImage *image, SDImageCacheType cacheType))doneBlock;

[cherpake]

Some additional info, i tried to fix this issue by:

1. removing the dispatch_sync in the diskImageExistsWithKey:(NSString *)key method - which resolved it, but scrolling between the images wasn't fluid (UI).
2. changing the macro dispatch_main_sync_safe to by async - made UI much more fluid and responsive

Now i saw that this change was introduced recently and probably for a good reason, but doing dispatch_sync on the main thread IMHO doesn't seem as a good idea, as it might be other wise busy, why not use dispatch_async here?

[cherpake]

One last note: checking this commit 3a6d948 i see that you turned a lot of async calls to sync calls, just saying.

[dperetti]

FYI, I'm experiencing the exact same issue at the moment :-)

[dreipol]

Got the same issue.
Please apply cherpakes patch, it fixes it.

[bpoplauschi]

Related to #509

[nicksnyder]

I can reliably reproduce this problem using SDWebImage 3.7.2, Xcode 6.2, in the iPhone 6 iOS 8.2 simulator.

See this project:
https://github.com/nicksnyder/iOS-UIWebView-vs-UITableView

[mythodeia]

@nicksnyder you produce the deadlock by setting the maxConcurrentDownloads to 1024. This sets the maxConcurrentOperationCount of the downloadQueue in SDWebImageDownloader to 1024 so NSOperationQueue will try to execute at the same time 1024 operations. This will surely hurt the system.
I tried it with as less as 70 in my system and still it deadlocks. 60 is the magic number for me to make it work

[nicksnyder]

I didn't mean to imply that 1024 was the smallest number needed to deadlock, but it does seem to vary based on the hardware being run on (which is why I put a silly high number in the bug report).

32 concurrent operations performs better than 3 (the default) in my project. I was manually searching for the sweet spot which is when I reproduced the deadlock. The deadlock is indeed still a bug with SDWebImage, right?

[mythodeia]

i think that the deadlock in SDWebImage occurs because of race conditions happening while requests are cancelled or finished. NSOperationQueue does not dequeue an operation until its finished state changes to true. So there might be some issues there.

[bpoplauschi]

Should be fixed by the latest 4.x branch changes (Redone the stuff from #781 by 062e50a f7e8246 c77adf4 265ace4 0c47bc3. Same stuff: replaced all sync calls to the completion with async, cleaned up the code a bit).