[webkit-reviews] review denied: [Bug 196372] Stop IDB transactions to release locked database files when network process is ready to suspend : [Attachment 368002] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 23 09:06:58 PDT 2019


Chris Dumez <cdumez at apple.com> has denied Sihui Liu <sihui_liu at apple.com>'s
request for review:
Bug 196372: Stop IDB transactions to release locked database files when network
process is ready to suspend
https://bugs.webkit.org/show_bug.cgi?id=196372

Attachment 368002: Patch

https://bugs.webkit.org/attachment.cgi?id=368002&action=review




--- Comment #13 from Chris Dumez <cdumez at apple.com> ---
Comment on attachment 368002
  --> https://bugs.webkit.org/attachment.cgi?id=368002
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=368002&action=review

> Source/WebKit/ChangeLog:20
> +2019-04-22  Sihui Liu  <sihui_liu at apple.com>

Double change log.

> Source/WTF/wtf/CrossThreadTaskHandler.h:47
> +    WTF_EXPORT_PRIVATE void waitForStop();

I do not think this name is right. It looks like to me this method is actually
stopping work, not just waiting. Maybe it should be name stopAndWait(),
similarly to pre-existing callOnMainThreadAndWait(). Or maybe suspendAndWait()
since there is a resume function. IF so, we should rename the members to use
"suspend" rather than "stop".

> Source/WebCore/Modules/indexeddb/server/IDBActivityCounter.cpp:39
> +static IDBActivityCounterObserver* countObserver = nullptr;

= nullptr is not needed since this is a static, it gets 0 initialized. Note
that you did not write "count = 0" above so you're already relying on this
behavior.

> Source/WebCore/Modules/indexeddb/server/IDBActivityCounter.cpp:41
> +void registerObserver(IDBActivityCounterObserver* observer)

I think this should be named setObserver() since you can only set 1 observer. I
would use register when you can register several.

> Source/WebCore/Modules/indexeddb/server/IDBActivityCounter.cpp:44
> +    countObserver = observer;

Should we assert that countObserver is nullptr before we set it?

> Source/WebCore/Modules/indexeddb/server/IDBActivityCounter.h:34
> +namespace IDBActivityCounter {

Maybe if we name this IDBActivity, we could rename the classes to shorter names
like "CounterObserver" and "AutoCounter".

> Source/WebCore/Modules/indexeddb/server/IDBActivityCounter.h:50
> +class IDBAcitivityAutoCounter {

Typo: IDBAcitivityAutoCounter

> Source/WebCore/Modules/indexeddb/server/IDBServer.h:61
> +enum class ShouldForceStop { No, Yes };

enum class ShouldForceStop : bool { No, Yes };

> Source/WebCore/Modules/indexeddb/server/IDBServer.h:129
> +    WEBCORE_EXPORT void stop(ShouldForceStop);

The name is unclear, the name is stop() and then there is a flag asking if we
should forceStop. What's the difference? This should be renamed to be clearer.
Maybe something like:
enum class StoppingPolicy { WaitForCompletion, Abort };

Cannot be sure of the naming since I am not sure I understood the behavior of
your code.

> Source/WebCore/Modules/indexeddb/server/MemoryIDBBackingStore.h:88
> +    bool hasTransaction(const IDBResourceIdentifier& identifier) { return
m_transactions.contains(identifier); }

const ?

> Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:247
> +	   IDBActivityCounter::IDBAcitivityAutoCounter autoCounter;

Wouldn't IDBActivity::AutoCounter look better?

> Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:936
> +    IDBActivityCounter::incrementIDBActivityCounter();

This method can return an error. Is it really OK to increment here even when we
end up with an error?

> Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:981
> +    auto result = transaction->abort();

Can this fail to abort? If so, is it OK to decrement unconditionally below?

> Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:1009
> +    IDBActivityCounter::decrementIDBActivityCounter();

This looks a bit fragile. Would it look better if we moved transaction counting
to IDBTransaction?

> Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:2707
> +bool SQLiteIDBBackingStore::hasTransaction(const IDBResourceIdentifier&
transactionIdentifier)

const ?

> Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.cpp:1635
> +    if (transaction->state() ==
UniqueIDBDatabaseTransaction::State::Aborted)

We usually prefer to switch() to make sure we deal explicitly with all enum
values.

> Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.cpp:2314
> +	   if (transaction->state() ==
UniqueIDBDatabaseTransaction::State::Aborting)

ditto about switch()

> Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h:96
> +    State state() { return m_state; }

const

> Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h:98
> +    IDBError result() { return m_result; }

Is IDBError a class/struct? IF so, this should return a const IDBError& and
this method would be const.

> Source/WebKit/NetworkProcess/NetworkProcess.cpp:140
> +	  
parentProcessConnection()->send(Messages::NetworkProcessProxy::SetIsIndexedData
baseHoldingLockedFiles(state == PAL::HysteresisState::Started), 0);

Why does IDB need special treatment? It is SQLLite based. So why cannot this
rely on NetworkProcessProxy::SetIsHoldingLockedFiles ?

> Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1063
> +void NetworkProcessProxy::setIsIndexedDatabaseHoldingLockedFiles(bool
isIndexedDatabaseHoldingLockedFiles)

Why a whole separate handling for IDB???

> Source/WebKit/UIProcess/Network/NetworkProcessProxy.h:263
> +    ProcessThrottler::BackgroundActivityToken
m_tokenForIndexedDatabaseHoldingLockedFiles;

Ditto


More information about the webkit-reviews mailing list