Re: [boost] [gsoc] Boost.Process done
Boris Schaeling <boris <at> highscore.de> writes: <snip>
If there are other ideas how to generate a unique name I can update the code (Windows provides an API to generate UUIDs but unfortunately it requires COM; on POSIX systems I'm not aware of any system function which could generate UUIDs).
Boris
For Windows, Neither UuidCreate nor UuidCreateSequential require COM. Are these not generally suitable for your needs?
On Fri, 27 Aug 2010 17:51:49 +0200, Adam Merz <adammerz@hotmail.com> wrote:
Boris Schaeling <boris <at> highscore.de> writes: <snip>
If there are other ideas how to generate a unique name I can update the code (Windows provides an API to generate UUIDs but unfortunately it requires COM; on POSIX systems I'm not aware of any system function which could generate UUIDs).
Boris
For Windows, Neither UuidCreate nor UuidCreateSequential require COM. Are these not generally suitable for your needs?
Thanks, you are right! I thought there is only CoCreateGuid. But what to do on POSIX systems? Reinventing Boost.Uuid doesn't make sense? Here's another idea: The behavior::named_pipe constructor accepts an optional parameter to set a pipe name. I could add a macro like BOOST_PROCESS_NO_BOOST_UUID which would remove Boost.Uuid code and require the caller to set a name. Then everyone is free to generate unique names with whatever functions are available? Boris PS: Found your posting by coincidence (for whatever reason it doesn't show up in the main thread on news.gmane.org) and replied a bit late now.
On 29.08.2010 23:27, Boris Schaeling wrote:
On Fri, 27 Aug 2010 17:51:49 +0200, Adam Merz <adammerz@hotmail.com> wrote:
Boris Schaeling <boris <at> highscore.de> writes: <snip>
If there are other ideas how to generate a unique name I can update the code (Windows provides an API to generate UUIDs but unfortunately it requires COM; on POSIX systems I'm not aware of any system function which could generate UUIDs).
Boris
For Windows, Neither UuidCreate nor UuidCreateSequential require COM. Are these not generally suitable for your needs?
Thanks, you are right! I thought there is only CoCreateGuid. But what to do on POSIX systems? Reinventing Boost.Uuid doesn't make sense?
Here's another idea: The behavior::named_pipe constructor accepts an optional parameter to set a pipe name. I could add a macro like BOOST_PROCESS_NO_BOOST_UUID which would remove Boost.Uuid code and require the caller to set a name. Then everyone is free to generate unique names with whatever functions are available?
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. IMO anonymous and named pipes should be in the Boost.Interprocess library. [1] UuidCreateSequential Function http://msdn.microsoft.com/en-us/library/aa379322(VS.85).aspx
On Tue, 31 Aug 2010 15:13:22 +0200, Ilya Sokolov <ilyasokol@gmail.com> 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. Adding another type like async_pipe could be a compromise though?
IMO anonymous and named pipes should be in the Boost.Interprocess library.
That would be OK for me although it wouldn't help much unless those types are designed similar to the behavior types in Boost.Process (derived from a parent class and providing methods like get_child_end() and get_parent_end()). Boris
On 01.09.2010 2:10, Boris Schaeling wrote:
On Tue, 31 Aug 2010 15:13:22 +0200, Ilya Sokolov <ilyasokol@gmail.com> 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.
On Wed, 01 Sep 2010 13:48:48 +0200, Ilya Sokolov <ilyasokol@gmail.com> wrote:
[...]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.
I think this is one question (where I don't know the answer to though). If in doubt I'd prefer to use anonymous pipes to avoid potential overhead of named pipes for synchronous I/O. It wouldn't be probably much anyway but then this is C++. :-) Another question is whether it's only us who can't imagine another use case. Maybe a developer wants to access the named pipe (the name can be returned through a parameter of the constructor and thus is available). I haven't thought about it deeply but would be careful to be more restrictive than we need to be. Boris
participants (3)
-
Adam Merz -
Boris Schaeling -
Ilya Sokolov