- Boost - lists.boost.org

Warnings in Boost.Thread
by Janusz Piwowarski 29 Mar '05

29 Mar '05

Hi all, When Boost.Thread is compiled in release mode, there are a lot of warnings about unused variable 'int loop_count' in read_write_mutex.cpp. They comes from code like: int loop_count = 0; while (m_state == -1) { BOOST_ASSERT(++loop_count == 1); ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; } If loop is for second evaluation of condition only, i think it would be better to write: if (m_state == -1) { ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; BOOST_ASSERT(m_state != -1); } Regards, Janusz

2 1

Re: [boost] Re: Classpath to C++ conversion
by Iain Hanson 29 Mar '05

29 Mar '05

> Do I understand this to mean that "ClassPath" is the entire Java > API? If not, you've failed to answer Dave's query on what > "Classpath" actually is. I have no idea what it is, so I > cannot discuss the merits of the idea for Boost. > Classpath is the GNU project for the full Java API. > > You didn't explain what GCJ is, and given that you used the term "GCJ > > classes" I'm beginning to think I don't really know what you mean by > > GCJ. > > I also don't know what "GCJ" is. IOW, I have no idea what this > proposal is for and can't comment on whether it is useful. > GCJ is the Java part of gcc. /ikh

1 0

repost: [Post review] Pointer Container
by Thorsten Ottosen 29 Mar '05

29 Mar '05

Dear all, I really need some feedback. Please comment! Thanks ------------------- The Pointer Container library is very almost finished. Since the review, the following major changes has been made - improved docs with new tutorial and improved browsing - new indirect functions - new Cloneable and Clone Allocator concepts - support for null values - refactored template interface off all classes - implementation guarantees to only instantiate std::container<void*> - rewritten iterators - improved tests The new docs, and code can be downloaded from the files section: http://groups.yahoo.com/group/boost/files/pointer%20container/ptr_container… The test runs with vc7.1 and gcc.3.3.3. Comments, suggestions and portability fixes are welcome. There are one major issue and one minor I need to have resolved during the post-review. Minor issue: allocation in map:operator[] ---------------------------------------- should a default allocated object use operator new or heap_clone_allocator::allocate_default(); ? This happens in ptr_map<string,int> m; m["foo"] = 5; // will allocate an int with new Normally the use can control all allocations because he always add objects manually or via cloninin (which he also controls). But the default object is just allocated with operator new inside ptr_map::operator[]. Should some hook be provided in a new allocator concept, map_heap_allocator? Major issue: ptr_iterator implementation. ----------------------------------------- So what is the problem? Well, since void* is used internally, the iterators must cast to the proper type in operator*; that is no problem for the default indireted iterators; the problem is with the iterators from ptr_iterator ptr_begin(); ptr_iterator ptr_end(); One way to define would be to say typedef internal_container::iterator ptr_iterator; Then the reference type would be void*& and not T*& as we would like. So if the user wanted to sort the container, he would do std::sort( cont.begin(), cont.end(), void_ptr_indirect_fun< std::less<T>, T>() ); This give us a rather insecure interface where you have to cast manually to T* inside the functor. So I wish we could get a T*& reference type. I think, from discussion with David Abrahams, that the current implementation is non-portable even though my test works: typedef T*& reference; reference dereference() const { // void_type is void* or const void* // I'm not sure why this is needed, but it seems to be return reinterpret_cast<reference>( const_cast<void_type&>( *iter_ ) ); } Does anybody knows how to rewrite this crappy code propoerly? I think we're faced with three options 1. keep the current behavior and describe in the docs that it is non-portable 2. go back to making ptr_iterator the default iterator with void*& reference type; 3. add a small subset of algorithms to the classes themselves; I'm thinking that the subset from std::list is appropriate: - sort - remove_if - remove - unique - reverse - merge Let me hear what you think best regards Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

1 0

[Boost-bugs] [ boost-Bugs-1164057 ] boost::filesystem::exists has bugs with UNC paths
by SourceForge.net 29 Mar '05

29 Mar '05

Bugs item #1164057, was opened at 2005-03-15 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1164057&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::exists has bugs with UNC paths Initial Comment: boost::filesystem::exists(path("//computer")) always fails, even if the computer exists. boost::filesystem::exists(path("//computer/share")) always succeeds, even if the share doesn't exist. The attached patch fixes this by: - always succeeding for //computer (this is better than always failing) - correctly detecting the existance or not of a share. (The problem here was that the code was missing an error code check) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1164057&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

9 14

Re: [boost] type_traits: recent changes break EDG compilations
by Ralf W. Grosse-Kunstleve 29 Mar '05

29 Mar '05

--- John Maddock <john(a)johnmaddock.co.uk> wrote: > I was able to track this down to some preprocessor logic - a particular > compiler workaround was being applied when it should not have been, so > cv-qualified member functions were not being detected as such - should now > be fixed in cvs. Yes, wonderful! With the latest CVS I am back in business. Thanks!!! Ralf __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: Boost.Threads bug?
by Michael Glassford 29 Mar '05

29 Mar '05

Alexander Nasonov wrote: > There is a less comparison in several places of time-related stuff. I > believe that less-or-equal is better. Take a look for example at if > statement here: [snipped example] This is now fixed. Mike

1 0

Singleton Documentation Complete
by Jason Hise 29 Mar '05

29 Mar '05

The documentation for the singleton is finished. I didn't end up writing a tutorial for extending the library after all, because it turned out that I already described the policy interfaces clearly in my reference section and didn't have much to add to them. Instead, I made sure that the tutorial had lots of links to the most important reference pages. New in this release is the addition of the cleanup class and the zombie singleton walk through. In addition, I did a bunch of minor bug fixing, most of which I don't remember, and most of which wouldn't affect most client code. I think one of the things I fixed was making sure that the malloc_creator frees the memory if construction throws. Anyhow, the new package is in the sandbox, enjoy! -Jason

11 40

Re: Asynchronous I/O
by Don G 29 Mar '05

29 Mar '05

Hi Jon, Thanks for the reply! Please see below for my responses. --- Jonathan Wakely <cow(a)compsoc.man.ac.uk> wrote: > How the kernel chooses to implement the aio system calls is an > implementation detail - it certainly doesn't require use of > Boost.Thread types! I think what Robert was saying is that an > application can use POSIX aio without ever having to use or > know about POSIX threads. But if it calls your callback on a thread other than main, you do care and need to know that detail. If the callback is called on the main thread, that thread either has to cooperate or for signals (again) be prepared to handle the special execution state inside the callback. > You and Don seem to be requiring that the application > explicitly create and manage threads. Several people have > suggested they'd like to use some form of AIO without having > to use threads. In the "Asynchronisity" thread, I suggest a mechanism that has certain thread-safe properties, but the user need never create a thread. That being said, I am proposing the the network layer (not the application) create and manage I/O threads. The callbacks it makes to the application would occur in those threads, but by using a technique like bind_async_call (see the "Asynchronicity" thread for details), the callback to user code can be delivered on the one and only thread that the user knows about. In pseudo code: char buf[256]; channel ch; stream::ptr st; int main () { nexus nx; ch.open(&nx); network::ptr net = ?; // create the network object st = net->new_address("foo:1234")->new_stream(); st->async_connect(ch.bind_async_call(&on_connect)); nx.pump(); // callbacks go until nx.close() is called } void on_connect () { st->async_read(buf, sizeof buf, ch.bind_async_call(&on_read_done)); } void on_read_done () { ... } Notice that all this is done inside main(). The user, however, must cooperate to deliver the async messages (the nx.pump() call). But this level of cooperation is required for most async mechanisms on most systems. I hope this clarifies what I am proposing. Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Asynchronous I/O
by Boris 29 Mar '05

29 Mar '05

While trying to find a reasonable interface for a socket class to support asynchronous I/O I was examining various implementations. Scott Woods had thought loudly about an asynchronous library which could be the platform for a network library and maybe others. I like this idea but look at this mess: 1) Signal-Driven I/O SIGIO is sent to a process whenever something happens with the socket. As there are too many things happening with a TCP socket the signal is generated too often and "signal-driven I/O is next to useless with a TCP socket" (W. Richard Stevens in his network bible). As there is just one signal handler per signal it shouldn't be used in a library anyway. 2) Threads There are different solutions possible eg. every thread calling a blocking function or one thread blocking while the other threads handle requests. However these are just variations of the blocking I/O model and multiplexing with the disadvantage of increased complexity because of threads. 3) AIO AIO is part of the Single UNIX Specification and an official standard for asynchronous input and output. The AIO API is based on file descriptors and defines a few functions inluding aio_read() and aio_write(). I/O is asynchronous because the process is notified when an input or output operation is completed - there is either a signal sent to the process or a callback function is executed (as a thread). Further more it is possible to poll a file descriptor if the process doesn't want to wait for the signal or the callback function. Now to the disadvantages: Linux 2.6 doesn't support AIO with sockets (see http://lse.sourceforge.net/io/aio.html) There are some AIO patches for Linux 2.4 but nothing official. Even if AIO support was complete there are no aio_connect() and aio_accept() functions. I wonder if connections have to be built up synchronously (I guess so as AIO wasn't designed only for sockets anyway). 4) I/O completion ports This I/O model is based on a concept called port. A port is similar to a multiplexor and waits for several input or output operations to complete. There can be several ports each multiplexing on several file descriptors. Windows XP, Windows 2000 Pro and Windows NT 3.5 support I/O completion ports. However the application has to call a blocking function for a port to be notified when an I/O operation is complete. 4) Event completion framework The event completion framework behaves like I/O completion ports. However the process can be notified of different types of events not only of the completion of I/O operations. Solaris 10 supports these events: AIO, timer, file descriptor, user-defined and waking up threads (see http://developers.sun.com/solaris/articles/event_completion.html) FreeBSD, OpenBSD and NetBSD support: read, write, AIO, file descriptor, process IDs (exit, fork etc. of other processes), signal, timer and network (see http://www.freebsd.org/cgi/man.cgi?query=kqueue&apropos=0&sektion=0…) The framework of *BSD is called kqueue and not compatible to Solaris. I don't know what other operating systems like Mac OS X support. There is kqueue() is their man pages (see http://developer.apple.com/documentation/Darwin/Reference/ManPages/index.ht…) but I don't know if it is supported. AIO doesn't seem to be supported. Microsoft operating systems provide WaitForMultipleObjects() since Windows 95 which supports these objects: change notification, console input, event, job, memory resource notification, mutex, process, semaphore, thread and waitable timer (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba…) Then I had a look at ACE as I wondered how they support asynchronous I/O with their Proactor class on different operating systems: They don't. They use this preprocessor directive in the beginning of Proactor.h: #if ((defined (ACE_WIN32) && !defined (ACE_HAS_WINCE)) || (defined (ACE_HAS_AIO_CALLS))) // This only works on Win32 platforms and on Unix platforms supporting POSIX aio calls. Someone wanted to port a Windows applications to Linux which was using the Proactor class. The ACE people told him he should say good-bye to Proactor (see http://groups.yahoo.com/group/ace-users/message/38548) Last but not least Linux 2.5 introduced a new API called epoll (see http://www.linuxmanpages.com/man4/epoll.4.php) It doesn't support asynchronous I/O but tries to get rid of all the disadvantages select() and poll() have. The Linux world seems to pursue the traditional multiplexing approach trying to improve it. Now who has an idea how the asynchronous C++ library should look like? ;) Boris

9 12

Asynchronicity (long)
by Don G 29 Mar '05

29 Mar '05

Hi All, I've renamed the subject from "Asynchronous I/O" because I wanted to float the notion that async behavior not be viewed as an aspect of I/O, though it is highly desired in that space. Below is a sketch and some pseudo-code of how I've done this over the past few years, in a portable manner. The trick to portability for me was integrating into various kinds of threads or main loops. For example: the main GUI thread of a Windows application, or a Motif (Xt) based application, or a Mac application's main event loop. These are the hard ones. Once they are possible, most (more likely "all") others are possible as well. Unfortunately, the needs of these integrators is not portable, but can be hidden behind simple wrapper classes for anticipated cases. To handle other cases, the integration mechanism needs to be visible. In the case of the GUI thread integrations, I have a single class to instantiate, though its details were wildly different for each platform. Depending on how this discussion goes, I plan to convert these ideas into a proposed library. Best, Don ------ Sketch -------- 1. The user creates one or more "nexus" objects. These objects store the queue of events, typically one-per-thread. Since some action is typically required as messages are enqueued, a callback is supplied to open() which gets called as each message is added. 2. The owner of the nexus is responsible for calling the pump() method to drain the messages. This method is intended for only one thread and hence is not internally thread-safe (i.e., BYOM ... Bring Your Own Mutex). 3. To queue calls, client code needs to create a "channel" object and connect it with a nexus. The reason for this object is that it is a proxy for the "ability to still dispatch a message". In other words, if a receiver object finds itself in its destructor, it will want to cancel any queued calls to it. Of course, this can be applied externally to objects, which is why channel is not a base class. 4. Once a channel is open, the async_call() method is used to put a message in flight. This is thread-safe. 5. Where other code needs a function<>, the channel can be used to create a shim function<> that accepts N arguments, and binds them into a queued call. ------ Pseudo-code -------- class nexus { friend class channel; public: typedef function<void (void)> message; // Return true if there is an object associated with // the current thread. static bool available (); // Return the object associated with the current // thread. Throw if there is none. static nexus & get_current (); // Connect this object with the current thread. The // ntfy callback is made whenever a message is added // to this queue. void open (const message & ntfy); void close (); // Remove a message from the queue. Don't wait any // longer than "t". If t == 0 and there is a message // in the queue, dispatch it now. void pump (const timeout & t = timeout::infinite); private: struct entry { channel * ch; message msg; }; typedef std::list<entry> messages; messages msgs_; message ntfy_; void enqueue (channel * ch, const message & msg) { msgs_.push_back(entry(ch, msg)); ntfy_(); } // Remove all entry's in msgs_ with == channel*. void purge (channel * ch); }; class channel { typedef nexus::message message; public: void open (nexus * nx = 0) { if (!nx) nx = &nexus::get_current(); close(); target_ = nx; } void close () { target_->purge(this); } void async_call (const message & msg) { target_->enqueue(this, msg); } // Create a callback that calls "this->async_call(msg)". message bind_async_call (const message & msg); // Create a callback that accepts T and calls // "this->async_call(bind(msg, t))". template <typename T1> function<void (T)> bind_async_call (const function<void (T)> & msg); // More flavors of bind_async_call() private: nexus * target_; }; __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1