Re: [Boost-bugs] [Boost C++ Libraries] #6049: Native handle access

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #6049: Native handle access
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2018-06-01 22:55:12

#6049: Native handle access
-------------------------------+---------------------------
  Reporter:  martin@…          |      Owner:  Ion Gaztañaga
      Type:  Feature Requests  |     Status:  closed
 Milestone:  To Be Determined  |  Component:  interprocess
   Version:  Boost 1.47.0      |   Severity:  Optimization
Resolution:  wontfix           |   Keywords:
-------------------------------+---------------------------

Comment (by mweikle@…):

 This seems to have been considered only in the Windows scenario, which I
 have no experience with.
 I'd submit it may be more pertinent in the case of *nix where spawned
 processes inherit all the open file handles of parent processes.
 It's only when you look deeply into your process resource usage when
 you're spawning processes and each is inheriting all the open file handles
 it doesn't need from a parent process that can't set CLOEXEC on them
 because it can't get the native file handle... So then you must need to
 close all your various memory segments between a fork() and exec() SO YOU
 DON'T REACH THE SYSTEM LIMITS OR PROCESS LIMITS... so what's the point in
 using this abstraction when it forces you to take such extraordinary
 measures?
 it seems inconceivable that someone would write a library for interprocess
 communication without taking this into account and then when it's brought
 up to summarily reject it without addressing the need.

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