Dear keren hochman: i think you might make the wrong command path.If you take care you may notice the path of bjam in your make error is "./tools/jam/src//bjam", see too slash before bjam. Hava a nice day:) boost-request@lists.boost.org 写道： Send Boost mailing list submissions to boost@lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request@lists.boost.org You can reach the person managing the list at boost-owner@lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ Today's Topics: 1. install boost_1_34_1 on fedora (keren hochman) 2. Re: [log] filtering performance (Andrey Semashev) 3. Re: [interprocess][process] Synchronizing libraries and efforts (+ bugs) (Ion Gazta?aga) 4. Re: [interprocess][process] Synchronizing libraries and efforts (+ bugs) (Ion Gazta?aga) ---------------------------------------------------------------------- Message: 1 Date: Mon, 1 Sep 2008 18:10:21 +0300 From: "keren hochman" Subject: [boost] install boost_1_34_1 on fedora To: boost@lists.boost.org Message-ID: <290181000809010810t4752a609s536c965814f9f504@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Im trying to install boost_1_34_1 on fedora (reference to http://www.boost.org/doc/libs/1_36_0...-boost-library ) But after make install i receive the following error message: bin/sh: ./tools/jam/src//bjam: No such file or directory Not all Boost libraries built properly. Could anyone advise me ? ------------------------------ Message: 2 Date: Mon, 01 Sep 2008 19:25:25 +0400 From: Andrey Semashev Subject: Re: [boost] [log] filtering performance To: boost@lists.boost.org Message-ID: <48BC0965.5040904@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Igor Nazarenko wrote:
It seems that the library does quite a bit of work before filtering away a record, unless the logging is turned off entirely. There's at least two mutex locks, some memory allocation, etc. Callgrind claims ~2500 instructions when the record is thrown away by the global severity filter. Shortened callgrind output is in-line below; full output and the test program attached. Compiled by gcc 4.2.3 using boost.build variant=release threading=multi.
Although I didn't extensively profile the code, I believe that is quite possible. ------------------------------ Message: 3 Date: Mon, 01 Sep 2008 17:44:56 +0200 From: Ion Gazta?aga Subject: Re: [boost] [interprocess][process] Synchronizing libraries and efforts (+ bugs) To: boost@lists.boost.org Message-ID: <48BC0DF8.10804@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Boris wrote:
-> Using named pipes has been problematic because it returns errors when launching multiple processes aggressively: Error 231 - All Pipes are Busy. This does not happen with anonymous pipes and I think it has some relationship with the guid code. By the way, I think a uuid library is too much to create a unique identifier to be shared with the child a simple atomic count would to the job in my opinion. That would reduce Boost.Process dependencies.
An atomic count might not be sufficient as it would be unique only per process. As I used Boost.Uuid only for convenience though I'll replace it with an atomic count plus a random number to drop the dependency.
The PID of the parent plus an atomic count wouldn't be enough?
-> systembuf::close() should call sync() to push the last charaters into the pipe, othewise, characters are lost if the user does not flush the stream.
Changed (in postream::close()).
I think we must change this in systembuf, because a user might use the streambuf directly and it would be surprised to see that unlike std::filebuf, already written characters are missed. Regards, Ion ------------------------------ Message: 4 Date: Mon, 01 Sep 2008 17:52:52 +0200 From: Ion Gazta?aga Subject: Re: [boost] [interprocess][process] Synchronizing libraries and efforts (+ bugs) To: boost@lists.boost.org Message-ID: <48BC0FD4.8010200@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Boris wrote:
On Sun, 31 Aug 2008 23:20:10 +0200, Ion Gazta?aga wrote:
[...]I understand async I/O should be tied with ASIO. I think Boost.Iostreams
To give you an idea how asynchronous I/O with Boost.Process and Boost.Asio currently looks like:
boost::process::child child; // somehow launched #if defined(_WIN32) boost::asio::windows::stream_handle out(io_service, child.get_stdin().handle().release()); boost::asio::windows::stream_handle in(io_service, child.get_stdout().handle().release()); #else boost::asio::posix::stream_descriptor out(io_service, child.get_stdin().handle().release()); boost::asio::posix::stream_descriptor in(io_service, child.get_stdout().handle().release()); #endif in.async_read_some(...);
I don't know ASIO but it's a shame that it does not offer a portable interface for async I/O.
[...]I can wait ;-) Since you are working hard on the library, I think it's better to wait until you consider the library mature enough. Feel free to contact me if you have any question.
OK, I'll tell you once I'm done (as I said I expect until mid September). The code is nearly done. But with all the changes which I had to merge I definitely need to update the documentation and samples.
Ok.
By the way, I would be very interested in a communication channel between a parent and a child process based on Boost.Interprocess. I need asynchronous I/O though. Before I picked up Boost.Process I had created a Boost.Asio extension boost::asio::shared_memory which can be used like boost::asio::socket. The only (but big :) problem I haven't solved yet is how to handle more than one communication channel. As read/write operations in Boost.Interprocess need to be synchronized the calls might block. A parent process with many children will then have to use at least one thread per child. What would be required is a demultiplexer which would work like select() for file descriptors. Then I think asynchronous I/O could be done with Boost.Interprocess. The question is though what would that demultiplexer look like? You are not working on supporting asynchronous I/O in Boost.Interprocess? ;)
I don't have much idea about async I/O but we can try to write something once we know what we need. I might be completly wrong but boost::interprocess::shared_memory_object is based on a file descriptor (shm_open in unix and a plan file on windows) so we can just obtain the handle and see if select() and WaitForMultipleObject() work on them. After all, write() should work on UNIX with a shared memory object descritor. Regards, Ion ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 2293, Issue 3 ************************************** --------------------------------- 雅虎邮箱，您的终生邮箱！