On Sun, Jul 6, 2008 at 7:26 PM, Boris <boriss@web.de> wrote:
On Fri, 04 Jul 2008 12:44:20 +0200, Chris Fairles <chris.fairles@gmail.com> 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