On 12/23/2009 06:13 AM, Sam Joyce wrote:
Hi Alan,
thanks for this. I hadn't realized this was the use pattern; more
comments in code please folks.
Perhaps you can add some while you still have the new-user perspective, that's
the best time to write documentation :)
looking at the add() fn, I see what you mean, it takes a copy, does the
add and then replaces the main array element.
I think CopyOnWriteArray is the correct type to use in the
HeadersExchange. Personally I like it because I get to use things like
add_unless() etc. (less coding for me) and I like the idea of a wrapper
class like this that protects the coder from having to manage the
locking directly; leads to less race conds because of misplaced locks.
From what you've mentioned below Alan, I'd guess the best option would
be to add a new method to CopyOnWriteArray, something like
replace_or_add(T& t, F f). the match function being the one to identify
an existing element. I'm open to ideas for a better method name :) I
think it should work a bit like add_unless(), except doing a
copy/remove/replace
thoughts?
regards,
Sam.
How about a general-purpose modify function like this:
// t takes a const vector<T>& , m takes a non-const vector<T>&
template <class Test, class Modifier>
bool modify_if(Test t, Modifier m) {
Mutex::ScopedLock l(lock);
if (array && t(*array)) {
ArrayPtr copy(new std::vector<T>(*array));
m(*copy);
array = copy;
return true;
}
return false;
}
That will let you do anything you like to the array - you could rewrite all the
modifiers in terms of this one (although they'd be a little less efficient
because the current ones use the results of the test part in the modify part.)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
