Bug 125333 – [Cocoa] Add load delegate methods for responding to authentication challenges

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Cocoa] Add load delegate methods for responding to authentication challenges

Created attachment 218568 [details]
THIS IS YOUR CHALLENGE

[Alexey Proskuryakov]

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.

[Darin Adler]

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

[Alexey Proskuryakov]

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

[Darin Adler]

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