Re: [Boost-bugs] [Boost C++ Libraries] #4827: Windows vs POSIX interface distinction seems unnecessary

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4827: Windows vs POSIX interface distinction seems unnecessary
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-04-02 17:28:25

#4827: Windows vs POSIX interface distinction seems unnecessary
-------------------------------+--------------------------------------------
  Reporter:  psiha             |       Owner:  igaztanaga  
      Type:  Tasks             |      Status:  reopened    
 Milestone:  To Be Determined  |   Component:  interprocess
   Version:  Boost 1.44.0      |    Severity:  Problem     
Resolution:                    |    Keywords:              
-------------------------------+--------------------------------------------

Comment (by psiha):

 Replying to [comment:8 igaztanaga]:
 > Sorry, but IMO your reply is too quick. Several users have reported bugs
 regarding non-administrative user permission issues, so shared memory is
 definitely needed for non-administrative users.


 Shared memory as such yes, but creation of global, kernel lifetime shared
 memory..is this also really required for non-admin users?



 > Maybe we should offer windows-centric new feature for permanent shared
 memory, but that's another story. Interprocess shared_memory_object is
 about portability. windows_shared_memory might be another issue.

 No, no...the point of the ticket was that there already exists an
 unnecessary Windows vs POSIX distinction in the interface...adding more
 windows-centric features would only make the problem worse...and, as you
 say, ...it is about portability...

 As explained in the boost.devel thread, this Win vs POSIX interface
 complication exists only because 'Boost.Interprocess' insists on the POSIX
 model that shared memory objects _must_ have kernel lifetime semantics on
 all platforms...If you give up on that premise, and provide two 'layers'
 or RAII wrappers for shared memory objects, one with scoped (or implicitly
 reference counted through the OS handle) life time semantics (like for
 normal C++ objects) and another with persistent/kernel life time this
 complication would (probably) vanish...Then you could implement the
 'plain'/scoped shm on Windows using the native shared memory mechanisms
 (as there would no longer be any need for the file-system-persistency
 emulation) which would in turn remove the need for the separate
 windows_shared_memory...

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/4827#comment:9>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.