[Webkit-unassigned] [Bug 196094] [GTK][WPE] Implement a basic DNS cache

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=196094

--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #8)
> Comment on attachment 372453 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=372453&action=review
> 
> I have a question about the threadsafety semantics. I was originally going
> to ask why you are using a lock in the DNSCache implementation, since I
> would have expected that would only ever be called from the main thread. But
> I see that is wrong, because GResolver is a global singleton, and global
> singletons in GLib are (probably) expected to be threadsafe (even though
> I've never seen any documentation indicate this clearly). OK then, the
> DNSCache is used by your WebKitCachedResolver, so makes sense for DNSCache
> to be threadsafe.

I have no idea. Patrick's patch was using a lock only to protect the cache itself, and that's what I've done here. 

> But WebKitCachedResolver is not itself threadsafe. So that doesn't make
> sense to me.

Why it's not? I think it is as long as the wrapped resolver is, and the default resolver is AFAIK.

> I have a suspicion that these will both only ever be used by WebKit on its
> main thread, so the DNSCache lock could be removed...? Is that not correct?
> If it's not correct, then I think WebKitCachedResolver needs its own lock.
> It just seems really suspicious that one has a lock but not the other.

I thought the same, but I'm just addressing my review comments here.

> > Source/WebKit/NetworkProcess/glib/WebKitCachedResolver.cpp:74
> > +WEBKIT_DEFINE_ASYNC_DATA_STRUCT(LookupAsyncData)
> 
> Huh, I didn't know we had this.

It uses fast malloc and allows to use C++ objects as members.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190620/d6f86673/attachment.html>