- Boost - lists.boost.org

behond IOStreams
by Carlo Wood 15 Sep '04

15 Sep '04

Hiya all. I already briefly discussed this with Jonathan Turkan and I understood he is interested to continue on a new project when IOStreams is accepted. I'd like to work together with him in this new project. In the past week I've done some "research" (between quotes because I still very new to this, can't call myself knowledgable yet). I'd start an early kick-off with this post ;). IOStreams can be seen as a library that allows one to define the following: Source --> filter --> filter --> Sink The relationship between the types involved can be delayed till runtime, but each individual type above has to be coded before that. It makes most sense to look at the above as instances instead of classes therefore (cause I did draw in the relationships between the different types already): Source_instance --> filter_instance --> filter_instance --> Sink_instance But for brevity I will not type the '_instance' part anymore. Obviously, we can have multiple Sources and Sinks at the same time: Source --> Sink Source --> filter --> filter --> Sink Source --> filter --> filter --> filter --> Sink Source --> filter --> Sink ... Each of these Sources will need to be handled by the Operating System; for example if they are sockets. In order to make an application work one will need "event demultiplexing" like forinstance is provided by select() or poll(). In order to write a framework that can "connect" the Sources and Sinks to this event demultiplexor in a flexible, portable and efficient way - a lot of design decisions need to be taken. Below I have made a list of a few topics that we can discuss, one by one - in order to make progress with these decisions. I am aware that there has been made a beginning with a design for such a framework already with boost in mind (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket) This design mainly considers sockets, but I think that a much wider approach is necessary (as we can discuss by following the points below). But of course we will use anything of this project that is useful. Another important source of experience is libACE. Although libACE provides everything we might need, it doesn't 'connect' well to boost; it has a lot of interfaces that are already done in boost but in another way. Also, I think that libACE is doing more than we need and not everything that we might want. If it were possible to write a more 'native' event demultiplexing library for boost then that will definitely add useful and additional functionality for the open source community. Apart from that, there is the license issue. I believe that the boost libraries are more 'free' then ACE, so in some cases ACE might not even be an option. ========================================================== Follows: Topics that can be discussed. I'd like to urge to stick to one Topic per thread. 1. Is there a need for this library? Should be a new effort like proposed or do we have to revive 'boost Sockets' and only build upon that without throwing things away? If "yes - there is a need for it and we might as well start with a clean plate": For the below I have chosen to phrase the topics as statements that I believe I can give sufficient argumentation for (if needed). 2. It is unavoidable that this library uses threads. 3. User programs compiled for platform A, and linking with a shared versions of this library - do not need to be able to run on platform B (with same architecture) without recompilation. 4. It is unacceptable that we would depend on other libraries (libevent, libACE) for this, except standard libraries (libc, libstdc++, socket, ws2_32, etc). 5. We should heavily lean on the expertise that is condensed in libACE for things like the following: There must be a concept "Event Handler" (the 'call back'). There must be a concept "Acceptor", "Connector" and "Handle" types. 6. The ideas about I/O filtering as discussed for Apache (see http://www.serverwatch.com/tutorials/article.php/1129721) need to be analyzed and probably implemented in IOStreams before we can really design the demultiplexor library. I will start a thread for each of these topics. Please reply to the first subject that you do not agree with (yet) only: it makes no sense to participate in discussions with a higher number if you disagree with the statement of one with a lower number :) Regards, -- Carlo Wood <carlo(a)alinoe.com>

10 54

Re:Re: [boost] serialization tests with intel 8.0 on linux
by Robert Ramey 15 Sep '04

15 Sep '04

Matthias Troyer wrote: >Shall I get you an account on a machine with that compiler? Latest test results seem to show this to be resolved. Thanks to whomever addressed. I'm sure it wasn't me. Robert Ramey

1 0

Re: Re: Re: IOStreams formal review -- extended
by Jonathan Turkanis 15 Sep '04

15 Sep '04

"Jonathan Turkanis" <technews(a)kangaroologic.com> wrote in message news:... > (i) buffering will be omitted, since it's hard to do correctly. > (ii) buffering will be provided, but mistakes in pointer arithmetic will cause > subtle errors > (iii) sub-optimal algorithms will be used. > > Note that two of Daryle's stream buffers suffer from defect (i). I didn't mean to imply that Daryle omitted buffering because it was hard -- I assume he had some other reason. Jonathan

1 0

Current cvs build broken (/boost/python/detail/signature.hpp)
by Neal D. Becker 15 Sep '04

15 Sep '04

/usr/local/src/boost.cvs/boost/python/detail/signature.hpp: In static member function `static const boost::python::detail::signature_element* boost::python::detail::signature_arity<11>::impl<Sig>::elements()': /usr/local/src/boost.cvs/boost/python/detail/signature.hpp:34: error: syntax error before `;' token...interrupted .

2 1

serialization tests with intel 8.0 on linux
by Robert Ramey 15 Sep '04

15 Sep '04

There are a group of test failures of the serialization library on intel 8.0 on linux. See http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html These are all associated with serialization of collections. I would guess that these are probably all variant manifestations of the same problem. Other interesting facts are: a) intel 7.1 passes on linux and win32 b) intel 8.0 passes on win32 Is there someone who has an interest in this platform would like to look into this? It would be very helpful. Robert Ramey

2 1

spirit 1.8 / vc 8.0 test results
by Robert Ramey 15 Sep '04

15 Sep '04

Spirit 1.8 with vc 8.0 is showing some test failures which impact the serialization library. In particular, the chest test is failing. Is this going to be addressed? Perhaps the vc 8.0 compiler being used for the test should be updated to the latest version if it hasn't been already. I think this would be very useful. Robert Ramey

3 2

problems with serialization regression tests
by Bronek Kozicki 15 Sep '04

15 Sep '04

I have a problem when running regression tests on Comeau compiler (toolset como- win32- 4.3.3- vc7.1) . Three tests: test_set_text_archive test_set_binary_archive test_set_xml_archive are taking above 1.5GB memory when running, thus my machine is slowing to crawl due to memory trashing (I have only 1GB RAM). I think there's something wrong with these tests? B.

1 0

Boost License Permission
by Kevlin Henney 15 Sep '04

15 Sep '04

I give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. Kevlin Henney -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

1 0

[filesystem]: bug and patch in path_posix_windows.cpp
by Angus Leeming 15 Sep '04

15 Sep '04

There are lots of "#ifdef BOOST_WINDOWS ... #endif" blocks wrapping code to handle the ':' in libs/filesystem/path_posix_windows.cpp. In one place only is the preprocessor block missing, which I believe is a bug. Patch attached. Silly test case. Without the patch, this: #include <boost/filesystem/path.hpp> #include <iostream> #include <string> namespace fs = boost::filesystem; int main() { std::string const PATH="/usr/local/bin:/usr/bin:/bin"; fs::path const path(PATH, fs::no_check); std::cout << PATH << '\n' << path.native_file_string() << std::endl; return 0; } Produces /usr/local/bin:/usr/bin:/bin /usr/local/bin:usr/bin:bin under *nix. Regards, Angus

2 1

recursive mutex and condition
by James Ahlborn 15 Sep '04

15 Sep '04

hey, I was wondering if any of the boost developers could tell me if recursive mutexes are supposed to work with conditions? From the code, it would seem to be the case, however in reality things aren't so happy. I have a fairly small test case which shows that the locking doesn't work if you recursively lock a mutex and then try to do a condition wait/notify. I'm testing this on red hat 7.3 and fedora core 2. My guess as to why it's broken is because the boost condition uses posix recursive mutexes internally, which also seem to fail the recursive mutex/condition test (at least on the OS's mentioned above). Anyone have any thoughts on this? I'll include my test case below. The error (for me) happens that when Thread2 releases the "inner" lock, Thread1 proceeds, even though Thread2 should still be holding the lock. (ps- i'm aware that there are some mem leaks in the program, i just simplified it for testing). thanks, -james ------------------------------------------------------- #include <string> #include <iostream.h> #include <boost/thread.hpp> #include <boost/smart_ptr.hpp> #include <boost/bind.hpp> using namespace boost; using namespace boost::detail::thread; class ThreadBase : private boost::noncopyable { public: void start() { m_thread.reset(new boost::thread(boost::bind(&ThreadBase::run, m_weakThis.lock()))); } void join() { m_thread->join(); } protected: virtual void run() = 0; ThreadBase() : m_thread(), m_weakThis() {} virtual ~ThreadBase() {} void initWeakThis(boost::weak_ptr<ThreadBase> weakThis) { m_weakThis = weakThis; } boost::shared_ptr<boost::thread> m_thread; boost::weak_ptr<ThreadBase> m_weakThis; private: }; class Thread2 : public ThreadBase { recursive_mutex* _mutex; condition* _cond; protected: Thread2(recursive_mutex* mutex, condition* cond) : ThreadBase(), _mutex(mutex), _cond(cond) {} public: static shared_ptr<Thread2> create(recursive_mutex* mutex, condition* cond) { shared_ptr<Thread2> tmp(new Thread2(mutex, cond)); tmp->initWeakThis(tmp); return tmp; } virtual ~Thread2() { cerr << "Thread2 dying\n"; } virtual void run() { cerr << "Thread2 acquiring lock(1)\n"; recursive_mutex::scoped_lock sl1(*_mutex); cerr << "Thread2 acquiring lock(2)\n"; { recursive_mutex::scoped_lock sl2(*_mutex); cerr << "Thread2 sleeping...\n"; ::sleep(5); cerr << "Thread2 signalling...\n"; _cond->notify_all(); cerr << "Thread2 releasing lock(2)\n"; } cerr << "Thread2 sleeping (again)...\n"; ::sleep(5); cerr << "Thread2 releasing lock(1)\n"; } }; class Thread1 : public ThreadBase { recursive_mutex _mutex; condition _cond; protected: Thread1() : ThreadBase() {} public: static shared_ptr<Thread1> create() { shared_ptr<Thread1> tmp(new Thread1()); tmp->initWeakThis(tmp); return tmp; } virtual ~Thread1() { cerr << "Thread1 dying\n"; } virtual void run() { cerr << "Thread1 acquiring lock(1)\n"; scoped_lock<recursive_mutex> sl1(_mutex); cerr << "Thread1 acquiring lock(2)\n"; { scoped_lock<recursive_mutex> sl2(_mutex); cerr << "Thread1 starting Thread2\n"; shared_ptr<Thread2> t2 = Thread2::create(&_mutex, &_cond); t2->start(); t2.reset(); cerr << "Thread1 waiting\n"; _cond.wait(sl2); cerr << "Thread1 releasing lock(2)\n"; } cerr << "Thread1 releasing lock(1)\n"; } }; int main(int argc, char** argv) { cerr << "Main Starting...\n"; shared_ptr<Thread1> t1 = Thread1::create(); t1->start(); t1->join(); cerr << "Main First Run\n"; // run it again t1->start(); t1->join(); t1.reset(); cerr << "Main Done\n"; return 0; }

1 0