|
Boost : |
Subject: Re: [boost] [gsoc] Boost.Process done
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2010-09-01 07:48:48
On 01.09.2010 2:10, Boris Schaeling wrote:
> On Tue, 31 Aug 2010 15:13:22 +0200, Ilya Sokolov <ilyasokol_at_[hidden]>
> wrote:
>
>> [...]As a user of the library, I'm not interested which pipes are used
>> for
>> I/O - anonymous or named. IMO it is better to provide exactly one
>> stream behavior which supports both sync and async I/O. On windows
>> it would be implemented with named pipe and UuidCreateSequential
>> (as it "tends to be slightly faster than the UuidCreate" [1]).
>> On POSIX it would be implemented with anonymous pipe.
>
> I could add another type (asnyc_pipe?) which is set to the minimum
> required pipe type on a platform? The advantage of pipe and named_pipe
> is though that many developers know them and don't need to read first
> what eg. an async_pipe is. As this is a problem only for Windows
> developers I'm not sure either why developers on other platforms should
> learn new concepts.
There is not much new in the concept of async_pipe. It is just a pipe
which supports async I/O. The alternative is to know what limitations
each target platform has and write something like this:
#ifdef _WIN32
ctx.stdout_behavior = bp::behavior::named_pipe::create(
bp::behavior::pipe::output_stream);
#else
ctx.stdout_behavior = bp::behavior::pipe::create(
bp::behavior::pipe::output_stream);
#endif
> Adding another type like async_pipe could be a compromise though?
If using named pipes on Windows for sync I/O is not slower than using
anonymous pipes, than there is no need for a separate type.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk