- Boost - lists.boost.org

[signals] Performance
by Jody Hagins 04 Apr '05

04 Apr '05

Are there any docs which describe the performance of the signal/slot library? I was about to embark on a performance study because I want to use it in a very high performance critical code path, but I thought I'd ask if anyone else may have already done some work in this area. Thanks!

12 35

Re: Asynchronicity (long)
by Don G 03 Apr '05

03 Apr '05

Hi Boris, No problem on the delay. I sometimes have long spells of silence due to work/family/church/life-in-general. :) My answers / opinions are below... --- Boris <boris(a)gtemail.net> wrote: > Hi Don, > > sorry for my late answer but work caught me again. At least > it's good to see others jumping in and keeping the > discussion alive. :) > > > [...] > > ------ Sketch -------- > > [...] > > It reminds me of I/O completion ports - several ports each > of them handling several events? Is your idea similar to this? It is similar, but the channel concept has no analogy. Then again, most async mechanisms are similar, it's just in the details that they diverge<g>. QueueUserAPC + SleepEx(ALERTABLE) is also similar, but again lacking the channel notion. The closest analogy in Windows is the USER thread message queue, an HWND and Get/DispatchMessage + PostMessage. I believe one can find nearly a one-to-one correspondence with that model. > > ------ Pseudo-code -------- > > > > class nexus > > The concept of the class really reminds me of a I/O > completion port. The only difference is that there is no > invisible background thread being responsible for a > nexus object - the application has to make sure that > there is one thread controlling a nexus object? Essentially, yes. Nothing is hidden with the possible exception of how does some body of code know the proper nexus object to which a channel should be connected. This can be explicit, but a thread-specific data item is also compelling. > > [...] > > class channel > > AFAICS you use this class to communicate with a nexus object. > The owner thread does the multiplexing (waiting for different > events in a nexus object) and other threads communicate with > this nexus object through channels which are responsible for > synchronizing? Is this correct? If I understand you correctly, Yes. The channel objects are the means by which the user enqueues events to a nexus object and a different piece of user code calls the nexus object to dispatch/dequeue the messages. > So the difference between your approach and I/O completion > ports in Windows is ... hm, I think in Windows a completion > port is a combination of your nexus and channel, isn't it? It is basically that, yes. The channel class, however, I believe to be a very important concept. Merging it with the nexus class would create dangerous situations where one would have to ask at the point a message is enqueued: "will it be OK to deliver this message regardless of what might happen between now and the time of delivery?" The key impulse that can make this answer always NO is "delete foo". The delete operation is synchronous. Without a channel to serve as a way to cancel pending messages to that object, we would have dangling pointers in the queue (a bad thing). Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 13

Re: [1.33.0] Release schedule suggestion
by Dave Gomboc 03 Apr '05

03 Apr '05

> I'll agree again. The changes I check in when we are in release mode (have a > release branch active) _always_ go to both the trunk and the branch. The > branch doesn't help me in any way. > > Apr 15: feature freeze > Release "when it's done" If "when it's done" is short enough, e.g. 2-3 weeks, then it's not even worth branching. Better to just concentrate on getting kinks out for the release. Is this at all realistic? Dave

4 7

Re: Proposal: intrusive containers
by Jaap Suter 03 Apr '05

03 Apr '05

> 1. Instead of providing the two options of deriving and embedding, let > the user provide ADL-style 'next' and 'prev' lookup functions that for a > given type provide hooks to the intrusive containers. "I'm not sure about this, most of the difficulty is involved in manipulating the links" Yes, the access provided to the links should obviously be referential so the containers can freely manipulate them. " - iterator adaptor or facade can be used to easily create iterators for types with their own next and prev pointers." It's not the iterators I'm worried about. It's being able to provide uniform STL-ish access to all my current intrusive containes. Inserting and removing elements from such containers becomes a lot more consistent, I believe. "If there was a check that a node wasn't in a container on insertion wouldn't these problems disappear?" Yes, but I don't always want to pay for this check if my own program logic dictates that I cannot possibly be inserting an item that already exists. In my own code, we have an 'insert' and a 'safe_insert'. However, occasional refactoring turns an 'insert' using piece of code into something that should be using 'safe_insert'. I'd like to be able to temporarily turn on invariant checking for a list when I'm working on the code around it, so I can make sure my changes didn't violate any conditions. Regards, Jaap Suter

1 0

Re: [1.33.0] Release schedule suggestion (David Abrahams)
by Dave Gomboc 03 Apr '05

03 Apr '05

> >If "when it's done" is short enough, e.g. 2-3 weeks, then it's not > >even worth branching. Better to just concentrate on getting kinks > >out for the release. Is this at all realistic? > > the reason for the branch is to that those developers who > need to work on > stuff NOT related to the release have someplace to put their > "commits". Yes, I know, but I also speculate that if the feature freeze time is short, then the number of Boost developers who "need" this is approximately zero. It's a plus if all developers are focusing on the actual release, so even if someone would otherwise be working on stuff for 1.34.0, if they are instead helping to clear regressions for 1.33.0, this means the 1.33.0 release will be ready sooner than otherwise. Dave

1 0

RE: [boost] Re: [Filesystem] Feature Request:Onemoreimplementationusing.NET
by Brian Braatz 03 Apr '05

03 Apr '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Holger Grund > Subject: [boost] Re: [Filesystem] Feature > Request:Onemoreimplementationusing.NET > > "Edward Diener" <eddielee(a)tropicsoft.com> wrote > > >>> I believe Microsoft will fix that bug in 2.0. > >>> The only disadvantage that it's not ready yet. > >>> > >>> So, may be we should postpone this question until 2.0 released? > >>> > >>> Anyway I don't think it's bad idea to do it with at least .NET 2.0. > > > > The problem is that the .NET classes themselves do not support templates > > as > > classes or as public or protected member functions. So moving any of > Boost > > to .NET essentially must drop the use of templates for the programmer > > using > > the implementation. > > That's not quite correct. You can have templates of managed types. > The C++ compiler will instantiate these as usual and create mangled > names which many existing languages targetting the CLR can't > access (they can still access methods via a base class). > > BTW: .NET 1.2 has never been released to the public and I think was > the CLR version used for some very early alpha (I think when we first > got the bits in July 2003, it shipped with a 1.2.30703 or something) > > VC++'s implementation of the C++/CLI language will enable you > to compile almost all of your existing C++ code to managed code only. > (the /clr:pure switch) > > That doesn't mean, however, that magically your code can be accessed > from other languages targeting the CLR nor that it will take advantage > of integrity/safety features of the GC memory system. If you want a > verifiable executable you simply need to rewrite your code (and you > can't use certain things in certain contexts like pointer arithmetic or > managed references as members ..) > > The language design is obviously intended to keep our (and oc, MS's > own) C++ assets. Just take your code compile with /clr and add > new managed functionality with the extensions of the C++/CLI > binding. > > So effectively, writing an implementation with the current structure > and using .NET classes for file system access gets you a whole lot > of nothing, I'm afraid. > [Brian Braatz Writes:] Forget Managed C++ Bad idea its going away (ugly too) The new CLI layer lets your code "be" C++ code and run in the dot net environment. You keep all the C++ performance by doing this. Only if you choose to expose something via the CLI mechanisms do you suffer performance issues with managed value\reference types Converesly, though what you gain is the ability to take your cpp code and selectively share out interfaces to it to other dot net libraries. Once you SHARE those things however you lose multiple inheritance and you cannot expose CPP templates. Additionally- the "sharing out" mechanism in CLI is akin to the PIMPL idiom (this is how CLI deals with you hooking the two worlds together) As Stan Lippman has said "C++ is multiparadigm. CLI is just another paradigm" The good news is you can use boost regex all day long. You can remain a CPP app , and you can share out functionality with dot net if you so choose.

1 0

[Boost-bugs] [ boost-Patches-1169756 ] Threads add additional assert to aid in debugging join()
by SourceForge.net 02 Apr '05

02 Apr '05

Patches item #1169756, was opened at 2005-03-24 01:55 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Threads add additional assert to aid in debugging join() Initial Comment: see discussion at http://article.gmane.org/gmane.comp.lib.boost.user/10093 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-02 15:03 Message: Logged In: NO added in Revision: 1.20, Tue Mar 29 16:19:32 2005 UTC by glassfordm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&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

1 0

typeof emulation internals
by Arkadiy Vertleyb 02 Apr '05

02 Apr '05

Hi all, While the work is being done to incorporate the latest MSVC-specific typeof trick under the proposed BOOST_TYPEOF umbrella, I would like to take one step back and offer a document that describes the internals of the typeof emulation. The document is related to so-called "compliant" implementation as opposed to Peder's "vintage" implementation. So, if anybody is interested, please take a look at typeof_internals.htm.zip in the Boost Sandbox File Vault, http://boost-sandbox.sourceforge.net/vault/. As always, any comments/suggestions are welcome. Regards, Arkadiy

1 0

Re: Asynchronicity (long)
by Don G 02 Apr '05

02 Apr '05

Hi Maxim, See below :) >>> What I might need is an event demultiplexor. Heavy >>> loaded servers I'm working on are event driven. Each >>> event which is not naturally a file descriptor >>> readiness change is transformed in a socket(pair) >>> write, so that it can be demultiplexed by >>> epoll_wait(). Thus, an application just handles >>> events in a loop around epoll_wait(). So, I might >>> need a little syntactic sugar around this stuff, but >>> I have not elaborated my generic implementation yet. >> >> This is exactly the kind of thing a general async >> library would solve for you. When something is done, >> instead of calling send/write on a socket that exists >> solely to make epoll happy, just queue the C++ call >> (i.e., a boost::function<> object). > > IMO, this contradicts with the thread title. I was intending to make a plug for the general async library (the topic of this thread) and how it should eliminate the need for hacks to make epoll_wait do the work (basically making all async operations into I/O operations). > Non-blocking and async are not the same. > > Non-blocking event model with select/poll/epoll is > when you get notified when a read or write won't block. > Async model with Windoze Overlapped I/O is when you get > notified when a read or write has been completed. The > latter is, IMO, higher level stuff and can be > implemented over the former (and this is how I've been > doing it in my projects). Now we have digressed to async I/O<g>, and while I agree with your definitions, one can always implement non-blocking on top of async (maybe not as efficiently as one would like). They are just different ways to manage concurrent operations. Sadly, not all systems support both models uniformly (jab at Windows). So, what we are exploring is just how can one write a portable, asynchronous application. Clearly the application's main loop cannot be based on non-portable techniques like epoll. Not that this makes epoll or libevent bad or wrong or anything, just not general enough for all of the async needs of a portable application. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Comments on functional/hash
by JOAQUIN LOPEZ MU?Z 02 Apr '05

02 Apr '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Sábado, Abril 2, 2005 1:03 pm Asunto: [boost] Comments on functional/hash > First of all, nice work! > > On headers: > > * boost::hash defined in <boost/functional/hash.hpp> > > Usually (when the number of top-level headers is small) we follow > the rule > that boost::X is defined in <boost/X.hpp>. This makes it much > easier for > users to remember what headers need to be included. > > I think that hash.hpp needs to be a top-level header. > It was my proposal to put it under <boost/functional/hash.hpp>, on the following rationales: * TR1 hash is located on <functional> * When John Maddock's Boost.TR1 inititative includes Boost.Hash, the naming conventions set up by John suggest that the wrapping header will be <boost/tr1/functional>, which is more consistent with <boost/functional/hash.hpp> than with <boost/hash.hpp> (IMHO). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 6