_Vasilisk_Это лучше.

обязательным копированием содержимого строки?

лучше просто очередь завести и в нее сбрасывать

_Vasilisk_,

TThreadQueue.Enqueue еще читабельнее

_Vasilisk_Не пофиг. Будет утечка памяти если не проверить результат и тупо обнулить

Это ее не устранит. Хотя вероятность понизит. Но устранит только гарантия "сообщение получено, за освобождение памяти теперь отвечает другой блок программы"

А "если проверить результат" - то ты просто передал какое-то сообщение Windows, не свеой программЕ, а операционке.

А оно было доставлено до нужного места программы? Может окошко раньше получило WM_CLOSE и закрылось ? Или даже не окно, а весь поток повис и был отстрелен? Или ReCreateWND случился и хэндл поменялся? Или это просто было не то окно, перепутали хэндл, и оно в принципе такие мэссиджи не умеет обрабатывать ?

ДокДля остальных случаях - только SendMessage

Если всё это в рамках одной программы - то SendMessage хорош только для однородности с PostMessage, чтобы одно в другое превращать заменой 4-х символов.
А в рамках VCL (и наверное LCL) вместo SendMessage есть TWinControl.Perform

Докя бы уж тогда лучше предпочел Queue

Судя по Synchronize ты имеешь в виду TThread.Queue

зачем создавaть сложный объект типа "анонимная функция", если передать нужно всего лишь одну строку?
лишние накладные расходы и лишняя возможность ошибиться.

нет, если мы передаём сложное и разнообразное поведение, тогда конечно

но если передать только данные надо - то и передавать надо только данные 21208990

ДокОбычно 2-3 параметра.

record или class

ДокКстати, а что ты имеешь ввиду под словом TThreadQueue.Enqueue? Мой гугл про это не знает.

Ну да, в отличие от TThreadList готового в Delphi нет, а потому и в FPC едва ли появится

но в общем

1) можно легко написать на базе TQueue<T> - просто все методы доступа (положить в очередь, достать из очереди, проверить есть ли что-то в очереди и т.д.) обернуть через TMonitor или TCriticalSection
Если не очень мощный поток данных - то хватит вполне. В общем ,смотришь как на основе TList<T> сделан TThreadList<T> и делаешь буквально то же с TQueue<T>

А записи разной структуры оборачиваются внутрь TValue (стандартного, либо какого-то стороннего, оптимизированного по скорости). Если вообще в одной очереди надо записи разных типов класть. Но это будет копирование данных. Лучше указатель на record передавать, либо объект (он сам себе указатель).

Кстати, кажется mORMot до появления в D2009 Advanced Record таки пользвоался старыми turboPascal-style объектами, потму что они намного быстрее создаются/убиваются, чем дельфийские классы. Как раз для передачи данных

2) в интернете полно статей на тему, недавно вышла одна, но там была очередь типа named pipes - в ней строго один писатель и строго один читатель, зато безблокировочная. Но опять же для delphi, насколько сложно ее перетащить будет в fpc/linux хз. Если можно, и читатель один (на примере другой ветки - в службе Windows 10 потоков перебирают окна и отсылают их названия в один поток, который пишет в БД), то никто не мешает для каждого потока генерящего данные завести отдельную очередь, а принимающий поток будет их по кругу осматривать.

3) кажется недавно кто-то переносил OmniThreadLibrary на FPC/Linux, но я сам не смотрел. Там очередь (iOmniBlockingColleciton) должна быть без блокировок. В принципе, если там на 90% сделано вдруг, то включиться в процесс "добить последние баги" можешь и ты.

Опять же в том же mORMot'e есть свой форк менеджера памяти SynScaleMM - там у каждого потока эксклюзивная lockless очередь блоков памяти на освобождение, куда другие потокаи скидывают "не свои" указатели из MemFree. Верятно ее можно за основу взять, если наивнйо блокировки (см. п. 1) не хватит.