[Mac] Spins seen in WKSetApplicationInformationItem, so it should not be called on the main thread

• Component: WebKit2
• Status: RESOLVED FIXED

[Darin Adler]

[Mac] Spins seen in WKSetApplicationInformationItem, so it should not be called on the main thread

[Darin Adler]

Created attachment 250167 [details]
Patch

[Alexey Proskuryakov]

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.

[Darin Adler]

(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.

[Darin Adler]

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.

[Darin Adler]

Committed r182366: <http://trac.webkit.org/changeset/182366>

rdar://problem/18773785