Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Daniel Trebbien (dtrebbien_at_[hidden])
Date: 2010-08-18 19:18:56

>> Is there a way to further remove platform dependence in handling the
"exit
>> code"?
>
> You mean the WIFEXITED et al macros? We had a status class in previous
Boost.Process versions which encapsulated the exit code. However the design
of the class was not really cross-platform as member functions like exited()
were clearly added for POSIX systems only and didn't make sense on Windows
(exited() for example always returned true). Thus the question is what to
make platform-independent if a concept doesn't exist on a platform. :-)

A while ago when I was thinking about this same problem, I considered using
Windows' debugging mechanism (process creation flag DEBUG_ONLY_THIS_PROCESS)
to obtain this information. I don't know if debugging a process will affect
its execution in some way, or whether the performance will be substantially
impacted, but it might be interesting to see if this approach would work.

>> * Templating of the char type to support wchar_t. The "wchar_t version"
>> would use the wide versions of Windows functions:  CreateProcessW, etc.
>
> The problem is then what to do on POSIX platforms (as there is no wide
version of execve() for example)?

While there is no POSIX equivalent of the wide char functions, I was mainly
thinking about using the `TCHAR` macro in cross-platform builds. Windows
programmers will probably be programming with TCHAR set to `wchar_t`, so if
the process creation library supported templating of the char type, then
there wouldn't need to be conversion of wide char strings to narrow char
strings. Plus, wouldn't there be a problem trying to execute a module on
Windows that has a non-Latin character in it?

>> * The ability to allocate within another process' address space, as well
as
>> read/write from/to another process' memory.
>
> I think you are looking for Boost.Interprocess. :-)

I read that the interprocess allocators of Boost.Interprocess require a
pre-existing shared memory segment. I was thinking about cross-platform
versions of Windows' VirtualAllocEx
function<http://msdn.microsoft.com/en-us/library/aa366890.aspx>which
allows blocks of memory to be allocated directly within another
process' address space, and
ReadProcessMemory<http://msdn.microsoft.com/en-us/library/ms680553.aspx>/
WriteProcessMemory
<http://msdn.microsoft.com/en-us/library/ms681674.aspx>for accessing
the memory.

>> * Integration with Boost Filesystem
>
> Where would you like to see support? Passing a path object to
create_child() for example?

For some reason it looked strange to me that the
find_executable_in_pathfunction returned a string rather than a Boost
Filesystem
path object. It's not that big of a deal, though, because I could construct
a path from a string if I really wanted.