New issue
Advanced search Search tips

Issue 640840 link

Starred by 13 users
Status: Assigned
Owner:
erikc...@chromium.org
Cc:
wfh@chromium.org
alexilin@chromium.org
erikc...@chromium.org
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 795291


Sign in to add a comment

Fix broken semantics for base::SharedMemoryHandle

Project Member Reported by erikc...@chromium.org, Aug 25 2016 
SharedMemoryHandle::Close() is a const method that calls CloseHandle() on the underlying handle_. But it doesn't touch handle_. 

SharedMemoryHandle::IsValid() just checks if handle_ is nullptr.

This means that SharedMemoryHandle::IsValid() returns true after SharedMemoryHandle::Close() is called. This is really confusing and should be fixed. I bet that all of these weird semantics stem from base::FileDescriptor.

Comment 1 by erikc...@chromium.org, Nov 2 2016 

More than just that, in an ideal world, SharedMemoryHandle would have appropriate ownership semantics. This isn't possible without updating all the consumers of SharedMemoryHandle to use appropriate move semantics, etc.

Comment 2 by wfh@chromium.org, Mar 23 2017

Cc: wfh@chromium.org
see also issue 412104

Comment 3 by erikc...@chromium.org, May 2 2017

Cc: erikc...@chromium.org
 Issue 716072  has been merged into this issue.

Comment 4 by thakis@chromium.org, May 2 2017 

Is this automatable? What are the transformations an automated rewriter would have to do?

Comment 5 by sebmarchand@chromium.org, Aug 14

Cc: alexilin@chromium.org
+alexilin@ : IIUC it's something you're addressing in your refactor of the shared memory API ?

Comment 6 by alexilin@chromium.org, Aug 14

Blockedon: 795291
Re c#5: yes, this is correct.
►

Sign in to add a comment