On Fri, Jul 4, 2008 at 6:26 AM, Stefano Delli Ponti <stefano.delliponti@gmail.com> wrote:

Boris wrote:

...

I stumbled over Boost.Process some months ago. The library was created as a Google Summer of Code project in 2006 (see http://www.netbsd.org/~jmmv/process/). As I needed the functionality provided by this library and didn't manage to contact the author I went through the code myself to tidy it up, fix various bugs, convert the documentation to DocBook etc.

Hello Boris,

I am very interested in this library and I have always thought it was an important missing piece in boost. I'm happy that you have taken over and revived the project.

I can organize some tests on a POSIX platform.

Regards, Stefano

...

I also added one minor but important improvement: With Boost.Asio 1.1 it's now possible to use asynchronous I/O (on Windows the macro BOOST_PROCESS_WINDOWS_USE_NAMED_PIPE must be defined as on Windows only named pipes support asynchronous I/O).

I've been using the library myself only on Windows so far where it seems to work fine. I didn't make any tests yet on a POSIX platform. I didn't update the documentation yet much either. And I have no idea how to integrate the samples and test programs into Boost.Build (there are two Jamfiles but don't be surprised if they don't work :).

As this library wasn't touched for nearly 2 years I don't know if there is any interest at all. As I had tidied up the code now anyway for my own purposes I provide a new snapshot for the community. You can find everything (including a link to download version 0.2) here: http://www.highscore.de/boost/process/

Boris

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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 I could also do some posix testing if needed. Cheers, Chris

On Fri, Jul 4, 2008 at 7:41 AM, Boris <boriss@web.de> wrote:

On Fri, 04 Jul 2008 12:44:20 +0200, Chris Fairles <chris.fairles@gmail.com> wrote:

Hi Stefano and Chris,

...

[...]

...

I am very interested in this library and I have always thought it was an important missing piece in boost. I'm happy that you have taken over and revived the project.

I can organize some tests on a POSIX platform.

the sample programs (in libs/process/example) and the tests (in libs/process/test) all compile fine on Windows. The only two tests which I couldn't check are posix_child_test.cpp and posix_launcher_test.cpp. If you can check if all the programs build successfully on a POSIX platform it would be already great!

I don't know if you have an idea what to put into the Jamfiles? I built all programs successfully with VC++ 2008 but didn't use Boost.Build. You probably need to invoke g++ or another compiler manually as it's very likely that the Jamfiles don't work.

...

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

There are so many modifications that I wonder if you used another Boost.Process snapshot. Did you use Boost.Process 0.1 from the Boost Vault? I ask as apart from your modifications in the POSIX parts there are other classes like boost::process::self which I've never seen before. Did you add this class or where does it come from? If you used Boost.Process 0.1 to make your modifications can you create a patch so I can see in detail what you changed?

To be honest, I can't recall where I got the original code from. It doesn't look I used 0.1 as the base. Attached is a diff between 0.1 and what I have in that repo. I have a feeling I got the original code from this list when someone like yourself posted an updated 0.1. When I get the time, I'll search the list and see if I can't find the post. Chris

Boris

...

[...]

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Boris, 2008/7/5 Boris <boriss@web.de>:

On Fri, 04 Jul 2008 14:52:01 +0200, Chris Fairles <chris.fairles@gmail.com> wrote:

[...]To be honest, I can't recall where I got the original code from. It

...

doesn't look I used 0.1 as the base. Attached is a diff between 0.1 and what I have in that repo. I have a feeling I got the original code from this list when someone like yourself posted an updated 0.1. When I get the time, I'll search the list and see if I can't find the post.

Thanks, I'll see if I can integrate the modifications into my version. And indeed you used a more recent version of Boost.Process although I couldn't find anything else than version 0.1 which is in the vault?!

The most recent code by Julio is in the boost sandbox: *http://preview.tinyurl.com/6qsg4z* I'm glad you've picked this up because it's a really useful library. Regards, Darren

Boris wrote:

Thanks for the link! I'm currently comparing the code and have already a question: There was a static constant defined in one class which has been changed by Julio to a static method (it had caused problems when the header was included in more than one compilation unit). Julio couldn't use the macro BOOST_STATIC_CONSTANT (see http://www.boost.org/development/int_const_guidelines.html) as on Windows a complex type is used which must be defined outside the class. While Julio simply defined a static method I had fixed the code with:

#if defined(BOOST_POSIX_API) || defined(BOOST_PROCESS_DOXYGEN) BOOST_STATIC_CONSTANT(handle_type, INVALID_VALUE = -1); #elif defined(BOOST_WINDOWS_API) # define INVALID_VALUE INVALID_HANDLE_VALUE #endif

Is there any guideline what to prefer here?

Macros as constants are pretty much shunned. Worse, the two options here have different behaviour if they're not on the global namespace. (And also if they are, since the macro prevents all other uses of the name.) Sebastian

On Sat, 05 Jul 2008 19:55:13 +0200, Boris <boriss@web.de> wrote:

[...]

...

Macros as constants are pretty much shunned. Worse, the two options here have different behaviour if they're not on the global namespace. (And also if they are, since the macro prevents all other uses of the name.)

I should have written the code differently:

#if defined(_MSC_VER) # define INVALID_VALUE INVALID_HANDLE_VALUE #else BOOST_STATIC_CONSTANT(handle_type, INVALID_VALUE = -1); #endif

Now it's obvious that the macro is a workaround for VC++ only. While Sebastian's points are valid do they justify to change a class' interface because of a limitation of one compiler? I've no preference (especially as VC++ is not an unimportant compiler of course).

As it turns out we are talking about private members of a class here. Thus I got rid of the static constant and macro and took over the static method from Boost.Process in Subversion (whatever version of Boost.Process that is). Boris

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