[webkit-reviews] review granted: [Bug 110600] webdatabase: Need a method for reliable multi-process quota management. : [Attachment 190770] the fix 2.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Feb 28 14:24:55 PST 2013


Geoffrey Garen <ggaren at apple.com> has granted Mark Lam <mark.lam at apple.com>'s
request for review:
Bug 110600: webdatabase: Need a method for reliable multi-process quota
management.
https://bugs.webkit.org/show_bug.cgi?id=110600

Attachment 190770: the fix 2.
https://bugs.webkit.org/attachment.cgi?id=190770&action=review

------- Additional Comments from Geoffrey Garen <ggaren at apple.com>
View in context: https://bugs.webkit.org/attachment.cgi?id=190770&action=review


Please resolve the design issues here before landing.

Let's do a follow-up patch to add an in-process Mutex to FileLock, so that it
provides exclusion between threads. (Otherwise, there's no real reason to have
a table of FileLocks.)

> Source/WTF/ChangeLog:24
> +	   * wtf/FileLockDarwin.cpp: Added.

Let's call this FileLockUnix.cpp, since the flock API is available on most
flavors of Unix and Linux. (See http://linux.die.net/man/2/flock.) This is our
convention for other classes like this.

> Source/WTF/wtf/FileLockDarwin.cpp:47
> +    m_lock.filename = filename;
> +    int length = filename.length();
> +
> +    m_lock.filenameCStr = new char[length + 1];
> +    strncpy(m_lock.filenameCStr, filename.latin1().data(), length);
> +    m_lock.filenameCStr[length] = '\0';

Let's not reinvent String=>CString conversion here. Instead, let's store just a
CString as a data member, and initialize it with filename.latin1().

> Source/WTF/wtf/FileLockDarwin.cpp:49
> +    m_lock.fd = open(m_lock.filenameCStr, O_RDWR | O_CREAT, S_IRUSR |
S_IWUSR);

It would be nice, in a follow-up patch, to hold the file open only as long as
it is supposed to be locked.

> Source/WTF/wtf/FileLockDarwin.cpp:58
> +    if (m_deleteFileFunc)
> +	   (*m_deleteFileFunc)(m_lock.filename.latin1().data());

Let's not use a deletion callback here. FileLock has its own fd for this file,
which it knows how to manage, regardless of what's happening in the
user-visible file system. Only our client knows when it's the best time to
remove the .lock file from the user-visible file system. That should happen
independently of releasing or deleting the file lock.

> Source/WebCore/Modules/webdatabase/DatabaseTracker.cpp:679
> +    FileLock* lock = m_fileLockMap.take(origin);
> +    if (lock)
> +	   delete lock;

Please use OwnPtr instead of manual pointer management.

> Source/WebCore/Modules/webdatabase/DatabaseTracker.cpp:681
> +    else
> +	   deleteFile(pathByAppendingComponent(originPath(origin),
String(".lock")));

This shouldn't be conditional.

> Source/WebCore/Modules/webdatabase/DatabaseTracker.cpp:848
> +	   deleteFileLockFor(origin);

This function should remove the lock from the table and also unlink the .lock
file.


More information about the webkit-reviews mailing list