Summary: | [Cocoa] Add load delegate methods for responding to authentication challenges | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mitz | ||||
Component: | WebKit2 | Assignee: | mitz | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | andersca, ap, darin, sam, thorton | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 125334 | ||||||
Attachments: |
|
Description
mitz
2013-12-05 20:53:43 PST
Created attachment 218568 [details]
THIS IS YOUR CHALLENGE
Comment on attachment 218568 [details] THIS IS YOUR CHALLENGE View in context: https://bugs.webkit.org/attachment.cgi?id=218568&action=review > Source/WebKit2/UIProcess/API/Cocoa/WKNSURLAuthenticationChallenge.mm:52 > + static dispatch_once_t token; > + static WKNSURLAuthenticationChallengeSender *sender; > + dispatch_once(&token, ^{ > + sender = [[WKNSURLAuthenticationChallengeSender alloc] init]; > + }); I don't understand how this works. I know that this is how we always use dispatch_once, and that man dispatch_once has this pattern as example, but I still don't understand how a regular static dispatch_once_t token can be used here without thread safe statics. And if we had thread safe statics, we'd just use static WKNSURLAuthenticationChallengeSender *sender = [[WKNSURLAuthenticationChallengeSender alloc] init]; > Source/WebKit2/UIProcess/API/Cocoa/WKNSURLAuthenticationChallenge.mm:69 > + [NSException raise:NSInvalidArgumentException format:@"The challenge was not sent by the receiver."]; Not sure what this error is saying. It seems like a regular situation when something is not sent by its receiver. (In reply to comment #2) > (From update of attachment 218568 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=218568&action=review > > > Source/WebKit2/UIProcess/API/Cocoa/WKNSURLAuthenticationChallenge.mm:52 > > + static dispatch_once_t token; > > + static WKNSURLAuthenticationChallengeSender *sender; > > + dispatch_once(&token, ^{ > > + sender = [[WKNSURLAuthenticationChallengeSender alloc] init]; > > + }); > > I don't understand how this works. I know that this is how we always use dispatch_once, and that man dispatch_once has this pattern as example, but I still don't understand how a regular static dispatch_once_t token can be used here without thread safe statics. I am not sure what part is not understood. The compiler option we use is documented as follows: -fno-threadsafe-statics Do not emit code to make initialization of local statics thread safe which has nothing to do with the value of uninitialized local statics. > And if we had thread safe statics, we'd just use > > static WKNSURLAuthenticationChallengeSender *sender = [[WKNSURLAuthenticationChallengeSender alloc] init]; Right. > > > Source/WebKit2/UIProcess/API/Cocoa/WKNSURLAuthenticationChallenge.mm:69 > > + [NSException raise:NSInvalidArgumentException format:@"The challenge was not sent by the receiver."]; > > Not sure what this error is saying. It seems like a regular situation when something is not sent by its receiver. “receiver” here is the receiver of the Objective-C message (i.e. 'self' in the context of this code). It is a programming error to do [s cancelAuthenticationChallenge:c] if s != c.sender. Comment on attachment 218568 [details] THIS IS YOUR CHALLENGE View in context: https://bugs.webkit.org/attachment.cgi?id=218568&action=review >>> Source/WebKit2/UIProcess/API/Cocoa/WKNSURLAuthenticationChallenge.mm:52 >>> + }); >> >> I don't understand how this works. I know that this is how we always use dispatch_once, and that man dispatch_once has this pattern as example, but I still don't understand how a regular static dispatch_once_t token can be used here without thread safe statics. >> >> And if we had thread safe statics, we'd just use >> >> static WKNSURLAuthenticationChallengeSender *sender = [[WKNSURLAuthenticationChallengeSender alloc] init]; > > I am not sure what part is not understood. The compiler option we use is documented as follows: > -fno-threadsafe-statics Do not emit code to make initialization of local statics thread safe > which has nothing to do with the value of uninitialized local statics. To me this looks correct. Committed <http://trac.webkit.org/r160227>. > I am not sure what part is not understood. The compiler option we use is documented as follows:
> -fno-threadsafe-statics Do not emit code to make initialization of local statics thread safe
> which has nothing to do with the value of uninitialized local statics.
Is "value of uninitialized local statics" a concept that actually exists in C++?
My understanding is that these are conceptually initialized, it's just that the initialization happens at magic times. And the magic doesn't guarantee the safety of this pattern is all compliant C++ implementations.
(In reply to comment #6) > Is "value of uninitialized local statics" a concept that actually exists in C++? > > My understanding is that these are conceptually initialized, it's just that the initialization happens at magic times. And the magic doesn't guarantee the safety of this pattern is all compliant C++ implementations. There is not a practical problem with this for dispatch_once tokens on any platform that we are using libdispatch with. But I see your point and there may be a theoretical problem on some other platforms. Local statics initialized to a constant are implemented the same was as “statics outside a function” (not sure these are the right terms). But you may be right that the C++ concepts for local statics that need to run code to initialize them may contaminate the behavior for these constant-initialized ones as well and create a theoretical portability problem. |