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: 2010-11-20 10:47:30

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

Comment (by psiha):

 Hi,
 yes OBJ_PERMANENT does require both SeCreatePermanent and
 SeCreateGlobalPrivilege. SeCreateGlobalPrivilege is IMO not a problem as:
  - administrators and services have it by default, which I consider a
 'normal'/reasonable requirement (admin/service/daemon level access) in a
 'secure' multi-user OS for any sort of global namespace 'pollution'
  - is required even by a Win32 solution (when not emulated with files
 ofcourse)...

 SeCreatePermanent OTOH is by default held only by (services running under)
 LocalSystem, however admins can gain it through impersonation. Considering
 that I can still imagine use cases/need for kernel-lifetime named shared
 objects only for special service/daemon types of processes and maybe
 special server-like applications (that one can reasonable expect to run
 with admin privileges) I'd say that IMO this still does not constitute a
 real problem.

 I've cobbled (and attached) a demonstration of the above and verified that
 it works on Win7 pro x64, Win7 home x64 and WinXP pro x86... ;)

 As argued in the first post on the boost.devel thread, regardless of the
 chosen underlying implementation, it is IMO wrong to make the majority of
 users/use cases (that do not require kernel lifetime shared objects
 capabilities) pay for the requirements of the minority by designing the
 interface (and then paying for it both in terms of 'fat' in the
 implementation and 'platform specific clutter' in the interface) in such a
 way as to always require/offer only kernel lifetime semantics...
 AFAICT an interface that would offer both scoped lifetime and kernel
 lifetime semantices would not suffer (or atleast suffer less) from the
 mentioned issues...

 Ad overhead:
  sizeof( mapped_region ) is 6 * sizeof( void * ) which is 5 (or 4 if you
 want to remember the size) sizeof( void * ) more than necessary (check in
 MSDN, it explicitly says that it is not necessary to hold on to the
 mapping handle but only the pointer returned by
 MapViewOfFile()...)...However this is less of a concern when compared to
 other 'unnecessary' things one has to pay for to get to/construct a
 mapped_region...i.e. for constructing a file_mapping one has to pay for a
 std::string, interprocess-to-win32 flags translation, exceptions,
 granularity adjustment... This sort of 'fat' if not obvious from source
 can be readily seen by stepping through assembly in release mode...or, as
 demonstrated in the post linked to in the original trac ticket 4234,
 comparing the sizes of statically linked binaries, VC 10 /Oxs:
 int main( int /*argc*/, char * * /*argv*/ ) { return 0; } ~ 31 kB

 int main( int /*argc*/, char * * /*argv*/ )
 {
     using namespace boost::interprocess;
     mapped_region region( file_mapping( "test", read_only ), read_only, 0,
 0 );
     return region.get_size();
 } ~ 49 kB

 ~18 kB difference for what is otherwise a half a dozen OS API calls is IMO
 a bit too much (alhtough still a lot better than Boost.IOStreams)...


 ps. maybe we should move this discussion back to boost.devel (considering
 the size of the posts)... ;)

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