Здравствуйте, McQwerty, Вы писали:

идея, да. но маленькие уточнения: я бы сделал так.

1. Объект назвал бы PostEventHandler.

Я бы сделал так: при старте программы сразу создал-бы поток.
Сбоку присобачил-бы очередь запросов. И событие, что очередь поменялась.

Все эти вещи по отдельности несут в себе не логичный смысл.

2. Закрытые члены PostEventHandler:
— дескриптор события;
— дескриптор потока.
3. Функцию потока я бы сделал статическим методом этого класса.
В конструкторе создавал бы объект событие и новый поток с использованием соответсвующих дескрипторов.
Событие естественно с ручным сбросом.
В деструкторе все уничтожал бы.
4. Указатель на экземпляр соответстсвующего типа передавал бы через механизм user data.
5. Очередь запросов естественно была бы закрытым членом PostEventHandler.

Порождённый поток ожидает события, просыпается, извлекает из очереди
первый запрос, обрабатывает, если очередь пуста — опять спит.

6. Инкапсулировал бы интерфейс добавления элементов в очередь и извлечения их оттуда.

Очередь запросов, конечно, нужно делать потоко-безопасной. Но это мелочи.

7. Отдельную конечную операцию работы с внутренним контейнером обрамил бы критической секцией.
8. В начале потока ожидание события, и затем работа над очередным запросом.

ГУЙ-поток при нажатии кнопки формирует запрос, помещает его в очередь,
поднимает событие и работает дальше.

9. В методе добавления элемента в список, в самом конце выставление события в сигнальное состояние.
10.В методе извлечения в конце с проверкой очереди на пустоту сбрасывание, если элементов нет.

При завершении работы ГУЙ-потока ставим в очредь спец-запрос: "кончай".
По этому запросу дополнительный поток завершается.

11.В деструкторе полное сворачивание всех внутренних ресурсов.
12. Счетчик элементов естественно собственностью очереди.

В первом приближении вроде все. Схема на первый взгляд логична, а остальные тонкости по месту отточил бы.