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

E>>Что значить заголовки другие? Вы, наверное, lib и приложение разными версиями компиляторов строите. И при этом еще и режимы компиляции (Debug/Release) и размеры выравнивания, и даже версии ACE разные используете?

AS>Перечитайте то, что я писал. Всего лишь перед заголовком ace включается что-то, что устанавливает FD_SETSIZE. Явно или неявно. И все, после этого ACE улетает в dev\null. Право, ну сколько можно это говорить .

Но ведь FD_SETSIZE настраивается в config-win32-common.h в ACE.
Если ACE используется совместно с какой-то другой библиотекой, устанавливающей свое значение FD_SETSIZE, то нет ничего сложного в том, чтобы определить в ace/config.h значение FD_SETSIZE перед включением config-win32.h.

E>>Вы написали:
E>>

E>>Я не про то. Событие, созданное при помощи WSACreateEvent, ждут при помощи WFMO. Надо ли объяснять, что при наличии LSP, который подменяет эти функции на свои (т.е. хендл события будет не обычным евентом) вся эта конструкция отправляется в dev\null. Ждать надо при помощи WSAWaitForMultipleEvents и точка — а это, очевидно, отправляет всю реализаци WFMO реактора в топку.

E>>Я сделал контекстный поиск по исходникам ACE 5.5.10 и ACE 5.6.3 и не нашел ни одного вызова WSACreateEvent. Так о чем вы говорите тогда?

AS>О том, что все очень печально. С сокетом можно ассоциировать событие, созданное только этой функцией. Теперь поищите по WSAEventSelect, и сделайте соотв. выводы.

А где говорится о том, что WFMO нельзя использовать вместо WSAWaitForMultipleEvents?
Нет, серьезно. WSAWaitForMultipleEvents выглядит как тонкая обертка над WFMO, может таковой она и является? MSDN не всегда достоверный источник информации, тем более, что если бы в WFMO нельзя было передавать дескрипторы сокетов, то WFMO_Reactor вообще бы не работал.

AS>Ну так попользуйте. Берем банальный перфоманс тест латентности, компилим (потратив ~день на сборку TAO+ACE), запускаем — работает. Выбираем в конфиге реактор на WFMO — и XP просто зависает (!!!!).

Ага, зависает XP (вау, что за чудная система, виснет из-за user-space приложения), а виноват ACE?

Собственно, зависание теста -- это еще не показалесь. Тесты зачастую пишут так, что далеко не все ошибки обрабатываются. WFMO_Reactor мог вернуть код ошибки, на которую не среагировал тест -- тест вполне мог зависнуть.

AS>Безусловно, ACE содержит в себе и очень много полезного кода, особенно для unix-like систем (например, только здесь я нашел ожидание посикс процесса с таймаутом, конечно, реализация спорная, но она есть), но вот win32 часть писали, к сожалению, далеко не профи. И это вылезает практически в любой строчке кода.

AS>В общем, подводя итоги. Я не вижу смысла продолжать обсуждение — свои претензии к ACE я уже высказал, в рамках этой ветки меня интересуют другие возможные либы, но никак не ACE или Poco Это мы уже пользовали, расхлебываем до сих пор. Нафиг-нафиг.

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

На отсутствие у ACE_Atomic_Op операции swap вы уже указали.
Еще одна претензия -- функция WMFO вместо WSAWFME.
На этом список не заканчивается, как я полагаю?