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

Subject: [boost] [GSoC] Some Ideas about the Boost.Process
From: Felipe Tanus (fotanus_at_[hidden])
Date: 2010-03-23 22:41:42

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