[Mac] Spins seen in WKSetApplicationInformationItem, so it should not be called on the main thread
Created attachment 250167 [details] Patch
Comment on attachment 250167 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=250167&action=review r=me assuming that there is a reason to believe that WKSetApplicationInformationItem can be used from a secondary thread. > Source/WebKit2/WebProcess/cocoa/WebProcessCocoa.mm:270 > +#if USE(APPKIT) We should probably use PLATFORM(MAC) now, as USE(APPKIT) is just a more confusing way to say the same. > Source/WebKit2/WebProcess/cocoa/WebProcessCocoa.mm:304 > + WKSetApplicationInformationItem(CFSTR("LSActivePageUserVisibleOriginsKey"), activePageURLs.get()); Is this function documented to be usable from a secondary thread? It doesn't seem obvious that it would be safe - there is waiting for an IPC response, and dealing with app global data structures here.
(In reply to comment #2) > Is this function documented to be usable from a secondary thread? Yes. It says "Mac OS X threading: Thread safe" in the header.
Comment on attachment 250167 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=250167&action=review >> Source/WebKit2/WebProcess/cocoa/WebProcessCocoa.mm:270 >> +#if USE(APPKIT) > > We should probably use PLATFORM(MAC) now, as USE(APPKIT) is just a more confusing way to say the same. I’m not sure what changed from when we first wrote the code, but I’ll do it. I think USE(APPKIT) is better than PLATFORM(MAC) when we are actually talking about AppKit, but I suppose WKSetApplicationInformationItem is hardly AppKit.
Committed r182366: <http://trac.webkit.org/changeset/182366>
rdar://problem/18773785