Re: [boost] Boost.Process 0.2 released

From: Chris Fairles (chris.fairles_at_[hidden])
Date: 2008-07-07 09:31:39

On Sun, Jul 6, 2008 at 7:26 PM, Boris <boriss_at_[hidden]> wrote:
> On Fri, 04 Jul 2008 12:44:20 +0200, Chris Fairles <chris.fairles_at_[hidden]>
> wrote:
>
>> [...]I've been using boost.process for quite some time. I've made some
>> hefty modifications to the posix parts to allow ptraceing of child
>> processes, the code is available here:
>> http://skotty.coffeebuzzin.com/browser/trunk/boost
>
> Chris,
>
> I've merged the code in the sandbox with my Boost.Process version 0.2. I'm
> going now through your POSIX-specific modifications.
>
> In boost/process/detail/pipe.hpp you've added a call to ::fcntl to make a
> pipe non-blocking. Is this something you needed for your own application or
> which you think should be part of an official Boost.Process library (if it
> ever is reviewed and accepted)? I see that the macro
> USE_NONBLOCKING_READ_PIPE needs be defined. But I wonder if it's not better
> to provide direct access to a pipe to the library user so he can set all
> kind of options himself?
>

I agree. It should be an option during the construction of pipe. I
think I added it so that ptrace worked correctly at the time. The
valid values for F_SETFL are O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME,
and O_NONBLOCK.

> Same question about ptrace and the various rlimit variables which were added
> to boost/process/detail/posix_ops.hpp - application-specific (added because
> you need them in your application) or in your opinion useful for all
> Boost.Process users?
>

Definitely not ptrace. The application I used this library for has a
parent process that intercepts system calls from spawned child
processes (using ptrace) and only allows a subset to be executed for
security purposes. I don't know what API in Windows provides similar
functionality (debuggers need to use *something* to interact with
kernel-level calls, have no idea what though) so it would be very
difficult to implement this in a portable manner.

The rlimit stuff has a similar purpose, limits the amount of time
child proc's can run, how much mem they can allocate, the largest file
they can create, the max number of open files etc. I think its more
useful than ptrace but I'm not sure if windows has similar control
over its proc's. If it does, then I think its worth having a portable
interface for setting resource limits on child processes.

HTH,
Chris

> I will need some more days before I can release another Boost.Process
> version as the test programs and documentation still need to be updated.
>
> Boris
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>