Boost logo

Boost :

From: ÐË ·ë (fxhnkf_at_[hidden])
Date: 2008-09-02 05:14:15

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_at_[hidden] дµÀ£º
  Send Boost mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

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:

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_at_[hidden]
Content-Type: text/plain; charset=ISO-8859-1

Im trying to install boost_1_34_1 on fedora (reference to
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_at_[hidden]
Message-ID: <48BC0965.5040904_at_[hidden]>
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
> variant=release threading=multi.

Although I didn't extensively profile the code, I believe that is quite


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_at_[hidden]
Message-ID: <48BC0DF8.10804_at_[hidden]>
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.




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_at_[hidden]
Message-ID: <48BC0FD4.8010200_at_[hidden]>
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.


> 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




Unsubscribe & other changes:

End of Boost Digest, Vol 2293, Issue 3


Boost list run by bdawes at, gregod at, cpdaniel at, john at