remove use of a boost::fast_pool_allocator without a mutex for Evoral::ControlList. this was not thread-safe and evidence from googling around suggests that it is actually not faster for this sort of use than std::alloc. removing this fixes bizarre errors caused by multithreaded use of the singleton pool that backs the allocator, which started to become more clear during experiments on 128 track sessions

git-svn-id: svn://localhost/ardour2/branches/3.0@13672 d708f5d6-7413-0410-9779-e7cbd77b26cf

1 files changed, 1 insertions, 13 deletions

diff --git a/libs/evoral/evoral/ControlList.hpp b/libs/evoral/evoral/ControlList.hpp
index 845a3b85d5..f43cf0af01 100644
--- a/libs/evoral/evoral/ControlList.hpp
+++ b/libs/evoral/evoral/ControlList.hpp
@@ -65,24 +65,12 @@ public:
 	double* coeff; ///< double[4] allocated by Curve as needed
 };
 
-
-/** Pool allocator for control lists that does not use a lock
- * and allocates 8k blocks of new pointers at a time
- */
-typedef boost::fast_pool_allocator<
-	ControlEvent*,
-	boost::default_user_allocator_new_delete,
-	boost::details::pool::null_mutex,
-	8192>
-ControlEventAllocator;
-
-
 /** A list (sequence) of time-stamped values for a control
  */
 class ControlList
 {
 public:
-	typedef std::list<ControlEvent*,ControlEventAllocator> EventList;
+	typedef std::list<ControlEvent*> EventList;
 	typedef EventList::iterator iterator;
 	typedef EventList::reverse_iterator reverse_iterator;
 	typedef EventList::const_iterator const_iterator;