Native handle access

[martin@…]

Allow access to the native object handle for all shared object types.

E.g. If you want to change the object rights(mutex, memory, events,...) via the WIN32 SetSecurityInfo() you need access to the native object handle.

[Ion Gaztañaga]

Windows synchronization utilities are not windows kernel based so there is no change to obtain a handle.

[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.