Re: [boost] [GSoC] Some Ideas about the Boost.Process

Subject: Re: [boost] [GSoC] Some Ideas about the Boost.Process
From: John B. Turpish (jbturp_at_[hidden])
Date: 2010-03-24 14:34:34

I'm in no position to answer your question. I just wanted to chime in
that I'm already using Boost.Process, and really like it. I'd like to
see it extended and someday become an official part of Boost.

If you're careful about what you do, you can write code that uses the
library without specifying the platform you're on, but I get what
you're going for here. Seems like a reasonable suggestion. As for the
first program argument - I already have my own helper function for
that, so for some like me there would certainly be a use, but I could
see reasons why someone would intentionally mess with argv[0]. Maybe
support the current API and add a convenience function?

I suspect that accepting any class that models a string would be quite
difficult, and probably not worth it.

On Tue, Mar 23, 2010 at 10:41 PM, Felipe Tanus <fotanus_at_[hidden]> wrote:
> Hello,
>
>        I have been studying the project idea about Boost.Process for a
> while. Some ideas/opinions poped up in my mind and I feel like to
> share. Please, comment.
>
>           IMHO, the best design for the library is not to split the
> APIs from Windows and POSIX. I Believe that boost should provide a
> higher abstraction level, and get rid of the platform problems.
>
> 1.The current implementation of Boost.Process library has the class
> boost::process::child, and two classes that inherit it, win32_child
> and posix_child. I don't believe that this is the best solution. There
> is only one concept of child in both APIs; some resources are
> different, it is true, but the concept is only one.
> For example, the call "boost::process::win32_launch()" is defined to
> launch a process "the windows API way", with the Win32 context. I
> don't see why can't we create a process with this  call in a POSIX
> system ignoring what don't apply to it (or find some similar concept
> and use it instead, as named pipes<->fifos). After all, if you are
> using a Win32 only class, there is no way to run in linux, so if the
> code works or don't, it does not matter. By doing this way, we could
> easy a possibly port to another system.
> This could be done with programming practices as suggested by Vicente
> Botet, in a previous topic [1]
>
> 2.The wait() method, to wait a process (child actually, but this is
> another problem) to die, is not asynchronous. Sometimes programmers
> want a synchronous wait() method, so there is no motive for we to
> remove this. We should implement a new asynchronous wait() method.
> This method should not be in the asio library, because it's process
> specific. It may require the asio library, or the asynchronous piece
> should be implemented in the boost.process. I'm not sure about this,
> both seems good for me, so please comment.
>
> 3.About the process creation, I think the following practice from the
> documentation should be avoided: “Another important requirement is to
> always pass at least one argument to the executable. This must be the
> name of the executable itself”. There is no motive to require a
> parameter that you can deduce by yourself. The first parameter, in
> this case, should be implicit.
>
> 4.Would really be nice boost::process::launch() be able to receive any
> kind of string? This tend to let the programmer go for a single
> platform solution. As a multiplatform library, this may be avoided.
> I'm not sure about this matter as well, but if the library is here to
> provide a higher abstraction level, should it also accept API related
> types? I believe it should not.
>
>        There is also another points that I would like to discuss in my GSoC
> proposal; They are well known problems so I'll just cite they:
>
> List and access other processes functionality
> Named pipes and FIFO (following the item #1, would be the same thing?
> Something would change? Something to be researched yet)
> move wait from child to process (as well as future asynchronous wait)
> Deal with process killing bugs (as well as any other known issue)
> Test platform issues.
>
> Should this be enough for a GSoC proposal? Do you have any other
> suggestion about what could I discuss in it?
>
> Thank you for your time,
>
> []'s
>
> [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/188736
>
> --
> Felipe de Oliveira Tanus
> E-mail: fotanus_at_[hidden]
> Blog: http://www.itlife.com.br
> Site: http://www.inf.ufrgs.br/~fotanus/
> -----
> "All we have to decide is what to do with the time that is given us." - Gandalf
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost