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-04 09:31:39

#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:10 igaztanaga]:
 > Interprocess insists on the POSIX model because it is the portable way
 that can be reliable and easily implemented in all OS and with all users.
 That's one of the main goals for all Boost libraries.


 I wouldn't be so eager to call this 'easy' considering the complications
 in implementation (the registry-temp-path dance,
 remove_shared_memory_on_destroy helper...) or even quite so portable
 considering the 'platform specific' 'pollution' of the interface...


 > In Interprocess review this was decided and it is not going to change.
 Windows reference-counted semantics are imposible to achieve reliably in
 POSIX (a process crash would leave the memory permanently) without kernel
 help and windows persistent shared memory needs special priviledges. So
 there is no discussion here.


 If "a possible process crash" was the only argument put forth in the
 review (I'm sorry I wasn't around then so I do not know) to justify this
 design then I beg to differ (on the "no discussion here").
 AFAIK Boost is not designed around bugs, UB, abnormal termination or
 'catastrophic failures' which, AFAICT, makes this argument bogus. Not to
 clean up memory mapped objects after a process is a POSIX design decision
 and Boost should not go out of its way to circumvent this first and
 foremost for the simple reason that it cannot. Even with the current
 Boost.Interprocess, if a POSIX-based process crashes (right) before the
 remove_shared_memory_on_destroy destructor is called the mapped object
 will also, AFAIK, 'leak'/'dangle'...Users using POSIX already are/have to
 be aware of this POSIX behaviour/semantics and be prepared to manually
 handle the cleanup (or decide not to)...

 ps. Windows persistent shared memory requires special privileges _for
 creation only_...is/was there a use case where a limited-user Windows
 application needs to create persistent shared memory?

 pps. no need to discuss reference counted semantics yet (I wasn't asking
 for those anyway), simple scoped mapped objects would be enough...



 > windows_shared_memory offers referece-counted semantics because they are
 useful for Windows users. Using OBJ_PERMANENT might be useful to implement
 shared memory for users accepting priviledge limitations, but not as a
 general solution.



 Well, at least having the option (to skip the emulation on Windows/use an
 alternate native implementation) would certainly be welcomed but it would
 still do nothing about the interface 'platform specificness'...

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