Avoid ThreadMessageQueue callback clashes when emptying queue

If a callback cleans up the queue, the next while-trypop loop could be problematic
This should also lessen mutex contention slightly

gf16/threadqueue.h

@@ -125,6 +125,19 @@ class ThreadMessageQueue {
 		return notEmpty;
 	}
 
+	// NOTE: unlike 'pop', this doesn't wait - it's more like trypop
+	std::vector<T> popall() {
+		std::vector<T> copy;
+		mutex_lock(mutex);
+		copy.reserve(q.size());
+		while(!q.empty()) {
+			copy.emplace_back(std::move(q.front()));
+			q.pop();
+		}
+		mutex_unlock(mutex);
+		return copy;
+	}
+
 	size_t size() const {
 		mutex_lock(mutex);
 		size_t s = q.size();
@@ -159,8 +172,8 @@ class ThreadNotifyQueue {
 #endif
 	) {
 		auto self = static_cast<ThreadNotifyQueue*>(handle->data);
-		void* notification;
-		while(self->q.trypop(&notification))
+		auto notifications = self->q.popall();
+		for(void* notification : notifications)
 			(self->o->*(self->cb))(notification);
 	}
 public:

src/gf.cc

@@ -956,8 +956,8 @@ class HasherInput : public node::ObjectWrap {
 		}
 	}
 	void after_process() {
-		struct input_work_data* data;
-		while(hashesDone.trypop(&data)) {
+		auto doneData = hashesDone.popall();
+		for(struct input_work_data* data : doneData) {
 			static_cast<HasherInput*>(data->self)->queueCount--;
 			data->cb->call();
 			delete data->cb;