WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
201074
CacheStorageConnection::computeRealBodySize is not thread-safe
https://bugs.webkit.org/show_bug.cgi?id=201074
Summary
CacheStorageConnection::computeRealBodySize is not thread-safe
youenn fablet
Reported
2019-08-23 05:31:04 PDT
CacheStorageConnection::computeRealBodySize is not thread-safe
Attachments
Patch
(2.58 KB, patch)
2019-08-23 05:34 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch
(2.33 KB, patch)
2019-08-26 01:57 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
youenn fablet
Comment 1
2019-08-23 05:34:07 PDT
Created
attachment 377122
[details]
Patch
Darin Adler
Comment 2
2019-08-23 10:40:12 PDT
Comment on
attachment 377122
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=377122&action=review
> Source/WebCore/Modules/cache/CacheStorageConnection.cpp:48 > + uint64_t resultSize; > + BinarySemaphore semaphore; > + callOnMainThread([sessionID, formData = formData.isolatedCopy(), &semaphore, &resultSize] { > + resultSize = formData->lengthInBytes(sessionID); > + semaphore.signal(); > + }); > + semaphore.wait();
Why is the semaphore needed? Doesn’t callOnMainThread, which is synchronous, already contain enough synchronization to guarantee the correct value for resultSize? If not, it seems really hard to program with callOnMainThread correctly.
youenn fablet
Comment 3
2019-08-26 01:55:17 PDT
(In reply to Darin Adler from
comment #2
)
> Comment on
attachment 377122
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=377122&action=review
> > > Source/WebCore/Modules/cache/CacheStorageConnection.cpp:48 > > + uint64_t resultSize; > > + BinarySemaphore semaphore; > > + callOnMainThread([sessionID, formData = formData.isolatedCopy(), &semaphore, &resultSize] { > > + resultSize = formData->lengthInBytes(sessionID); > > + semaphore.signal(); > > + }); > > + semaphore.wait(); > > Why is the semaphore needed? Doesn’t callOnMainThread, which is synchronous, > already contain enough synchronization to guarantee the correct value for > resultSize? If not, it seems really hard to program with callOnMainThread > correctly.
Using callOnMainThread does not wait, but I should replace the semaphore with a call to callOnMainThreadAndWait.
youenn fablet
Comment 4
2019-08-26 01:57:46 PDT
Created
attachment 377236
[details]
Patch
Chris Dumez
Comment 5
2019-08-26 09:11:27 PDT
Comment on
attachment 377236
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=377236&action=review
> Source/WebCore/Modules/cache/CacheStorageConnection.cpp:38 > + if (isMainThread())
This branch is not really needed, callOnMainThreadAndWait() already does the right thing for you. Or are you doing this as an optimization to avoid the isolatedCopy() of the FormData? I guess that's fine.
youenn fablet
Comment 6
2019-08-26 10:13:27 PDT
(In reply to Chris Dumez from
comment #5
)
> Comment on
attachment 377236
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=377236&action=review
> > > Source/WebCore/Modules/cache/CacheStorageConnection.cpp:38 > > + if (isMainThread()) > > This branch is not really needed, callOnMainThreadAndWait() already does the > right thing for you. Or are you doing this as an optimization to avoid the > isolatedCopy() of the FormData? I guess that's fine.
Yes, there is no way we could optimise this.
WebKit Commit Bot
Comment 7
2019-08-26 10:51:24 PDT
Comment on
attachment 377236
[details]
Patch Clearing flags on attachment: 377236 Committed
r249105
: <
https://trac.webkit.org/changeset/249105
>
WebKit Commit Bot
Comment 8
2019-08-26 10:51:26 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 9
2019-08-26 10:52:18 PDT
<
rdar://problem/54713221
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug