[Webkit-unassigned] [Bug 192714] New: Unify SharedMemory factory functions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 14 13:29:40 PST 2018


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

            Bug ID: 192714
           Summary: Unify SharedMemory factory functions
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aperez at igalia.com

Currently, the following factory functions are available:

- SharedMemory::create(uint8_t*, size_t, Protection), used directly
  in NetworkCache::Data::tryCreateSharedMemory(), and in the content
  extensions code to obtain a SharedMemory object to pass to other
  processes from a mapped file. The latter is only used in the Cocoa
  port.

- SharedMemory::wrapMap(uint8_t*, size_t, int), used only in the libsoup
  implementation of NetworkCache::Data::tryCreateSharedMemory(). This
  takes a mmap address+size and its file descriptor, and the intention
  is the same as Cocoa's ::create, but here being called ::wrapMap
  (which is incoherent).

- SharedMemory::adopt(HANDLE, size_t, Protection) for the Windows
  implementation is used internally in SharedMemoryWin.cpp but
  nowhere else, and the intention seems to be different from the
  two previous ones: in this case it takes a file handle, and
  memory-maps it (instead of taking an *existing* map). This
  should be private.

I would like to propose picking the same name for the first two
cases, and IMHO the name ::wrapMap() better indicates the intention.
Also, I want to make the functions private: the only use is inside
NetworkCache::Data::tryCreateSharedMemory(), so that could be marked
as “friend”; and the usage of ::create() in the content extensions
converted to a call to ::tryCreateSharedMemory().

-- 
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/20181214/1ddd8ba6/attachment.html>


More information about the webkit-unassigned mailing list