Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]

Subject: Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2011-02-14 10:45:44

On Sat, Feb 12, 2011 at 20:14, Oliver Kowalke <k-oli_at_[hidden]> wrote:

> Am 12.02.2011 19:51, schrieb Jeremy Maitin-Shepard:
>
>  On 02/11/2011 11:33 PM, Oliver Kowalke wrote:
>>
>>> [snip]
>>> I agree - boost.process should provide only the sync. wait (async. wait
>>> should be left).
>>> Maybe boost.process or another library can provide the async. wait
>>> facility and the community has more time to discuss it.
>>>
>>
>> With only synchronous waiting, the library is fairly limited in utility.
>> I would think that the sort of scripting tasks that synchronous waiting
>> might be useful for would not likely be done in C++ to begin with.
>>
>
> you could implement async. wait with thread and future + sync. waiting (I
> know this solution has its limitations).
> the async. waiting shouldn't a show stopper for boost.process - as this
> thread shows more discussion is required for a careful design of async.
> waiting (at least on POSIX -> interaction with other signals).
> It can be added in the prospective development of boost.process.
>

Hi,

I'm observing the developpement of Boost.Process for a project for wich I
(will later) need a main application to launch children processes,
communicate with them AND know when they end, whatever the reason
(sucessful, not successful and any kind of crash).

As far as I know, from a previous discussion on this list, async_wait might
be the only (cross-platform) way (without having to add another dependency
than boost to the project...) to achive the last point, knowing when the
child process ends.

About the "thread and future + sync. waiting" way of doing it : would it
work with any kind of child process end (including any kind of crash)?  Or
is it part of the limitations you're thinking about?

About the initial question, I've always thought that Boost.Process would
provide :
 1. A cross-platform way to manipulate processes (child processes) including
managing their "life-time".
 2. Maybe some platform-specific utilites.
 3. Easy Inter-process communication "would be cool" but as there is another
library providing this feature, is not a show stopper for me.

That don't include "efficiency" as personnally I wouldnt' assume that an
abstraction of such manipulations would have a chance to be as fast as
platform-specific API usage.

Whatever the implementation (through platform-specific defines or
plateform-specific cpp files), as far as I don't see platfrom specific-code
in my own app and the abstract behaviour is the same on all platforms (if
details changes I don't really care), that's fine.
My other solution --if boost.process isn't stable enough for my need at the
moment I'll use it directly in my app-- being to just isolate myself
plateform-specific API calls, but I'm a bit worried about the child ending
notification feature (because I'm not a specialist at all).

That's the advice of an humble non-boost-dev-level boost-user, so it might
be naive.

Joël Lamotte