Есть приложение, работающее под Vista в текущей WinSta и на активном десктопе, устанавливающее глобальный хук.
Хук, само собой, в dll.
Результаты работы хука передаются в приложение.
Данных по объему за 1 передачу мало, вполне хватило бы и PostMessage, если бы не особенности работы очереди сообщений в Vista (см. описание hWnd параметра).

По совету попробовал задействовать NamedPipes, само собой - воспользовавшись готовыми компонентами, ибо плодить велосипеды неохота.
Пробовал: Pipes от rllibby; CiaPipes от не_помню_кого, пример Игоря Шевченко, который так и не смог адаптировать под свои нужды :(
В результате столкнулся со следующими проблемами:
1. Эти компоненты нормально работают, если создаются из основного потока VCL-приложения и отвратно, если из доп.потока. Отвратность не поддается описанию, когда работа производится в хуке в контексте другого приложения. Заключается отвратность в том, что создание и передача данных производятся нормально, но при завершении работы приложения, установившего хук, внутри Pipe-компонентов происходит замораживание на Wait-функциях (ждет SetEvent). Причем - даже при завершении в штатном режиме.
"Хукнутые" приложения в результате этого просто зависают.
Попытки разобраться в коде ни к чему хорошему не привели - я слабо понимаю работу ф-и SetEvent, а в этих компонентах вся синхронизация построена именно на ней. Менять ее на более мне привычные CriticalSections - это переписывать весь код.

2. Работа этих компонентов и примера Игоря Шевченко основана на создании для каждого подключения дополнительного потока, что в условиях моей задачи весьма расточительно, т.к. подключений будет куча.

Проблема 1 частично решена использованием вместо PipeClient обычного TFileStream.
Осталась проблема №2 и частично №1 в плане использовани PipeServer.

Собственно - вопрос:
возможна ли реализация PipeServer без создания для каждого подключения дополнительного потока?
В крайнем случае - реализация PipeServer, которая по Вашему мнению не имеет проблем с синхронизацией.

P.S. C удовольствием бы воспользовался для передачи данных из хука в свое приложение сокетами (моя родная стихия), но пользователя инфаркт хватит, когда файрволл сообщит, что "Notepad пытается получить доступ к сети" 

kami, 

Код не можешь прикрепить для тестирования?
Может удастся подумать...

Попробую минимизировать, бо там столько всего...
А просто форму с брошенными на нее компонентами не получится, ибо 

Попробую. Как получится - скину код.

Хорошо.

Добавлено через 6 минут и 23 секунды
kami, 
Сорри, я и забыл, что уже на Windows7 перешел с Висты... Хотя может и под семёркой то же самое будет.

А на самом деле без разницы.
Особенности поведения PostMessage начались с Висты и будут продолжаться дальше.
А вот особенности поведения компонентов, реализующих функционал NamedPipes от операционки не зависят, если она >=W2k.

код во вложении, сразу с использованными компонентами.

Присоединённый файл ( Кол-во скачиваний: 10 )
 PIPES.zip 35,12 Kb

эм, может проще mmf?

dumb, 
Каким образом, если нужен принцип:
много источников данных сообщают их одному приемнику. Постоянно.
Данные должны передаваться практически мгновенно. Обратная связь не нужна.

Если покажете, как с помощью mmf можно организовать стек FIFO или что-нибудь в этом роде - буду только рад, т.к. моих скромных знаний хватит только на добавление данных в конец mmf. А вот как их убрать из начала, чтобы файл подкачки не распухал - не знаю.

мне так показалось, что этого вполне достаточно. хотя может я не до конца вник в суть.

а разве необходимо убирать по одному? - почему нельзя вычитать все и "обнулить"?

Тогда я чего-то не понимаю.
mmf, afaik создается конкретного размера:

Допустим, создаем с запасом (хотя - с каким, не понимаю), в начало я добавлю количество структур данных.
т.е. получится что-то вроде
THookStruct=record
  StructCount:integer;
  StructItems:array of TRect;
end;

следующий момент:
нужно добавить очередную запись в конец из хука.
считываем количество записей, в этот момент планировщик потоков отдает управление моей программе, которая обнуляет все имеющееся в mmf.
Управление переключается обратно в хук, который увеличивает на 1 количество записей (которых на самом деле уже не n, а 0) и добавляет данные в конец mmf.
В результате - значимой будет только последняя запись, а остальное - пустышки. И это в лучшем случае, если управление будет передаваться на границах операторов, а не "посредине" их.

Что я не так понимаю?

по-хорошему, прикинуть скорость поступления событий и частоту их выборки, и сделать c x-кратным запасом. если не париться, то сделать 1мб и все. 

эм... я полагал, что блокировка доступа к общему ресурсу(mmf) при много-поточной работе - это очевидное. прошу пардона. 

блокировка схематично:

/me сгорает_от_стыда_за_свою_глупость.

Попробую, отпишусь. Скорее всего, так и сделаю.

Единственное, что остается, и что действительно "парит" - 

В принципе - 
SizeOf(TRect)=16b, 
1Mb/16b=65536 записей.
Ххххххто его знает - много это или мало 

P.S. все-таки, хотелось хоть немного разобраться с NamedPipes, можно ли сделать реализацию Pipe server -а однопоточным 

Чтобы долго не держать тему открытой (лучше потом еще создам), закроем ее.
По совету dumb, будет следующая реализация:
при внедрении dll в процесс будет создаваться доп.поток, который будет разруливать обмен по mmf (чтобы, в соответствии с рекомендациями MSDN, не задерживать на ф-и хука). Передача внутрь доп.потока будет идти по PostThreadMessage, что лучше всего соответствует изначальным требованиям и минимизации времени выполнения хука.
Дальше - действительно "по дефолту", как и описал dumb.

Всем спасибо.