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

Угу, и если таких библиотек несколько ,получаем веселый зоопарк "кто вперед". На самом деле, все просто. Не использовать это в ACE_Handle_Set, а тому, кто написал это чудо — просто руки вырвать. С корнем

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

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

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

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

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

Дескрипторы сокетов туда никто не передает. Туда события передают
А вообще, у них даже тип разный WSAEVENT и HANDLE. Да, на самом деле это тонкая обертка (сейчас), но кто гарантирует, что так будет и дальше? Ответ — никто.

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

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

И он тоже. В MSDN ясно написано — 64 хендла. ACE пробует больше.

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

Зависла система, а не тест Из-за кривого реактора.

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

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

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

Могу, но не вижу смысла, поскольку есть библиотеки, где нет явных ляпов .

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

Например:
ACE_Process/Options
1. Terminate на хендл.
2. kill не работает.
3. Process_name, сомманд лайн и многое другое хранится в фиксированном буфере. Доколе, блин!
4. Содержит обекты ACE_Handle_Set (FD_SETSIZE).
5. При редиректе хендлов некорректно отслеживается ошибки дупликации (не удаляются ранее сдуплицированные хендлы). При этом при освобождении хендлов (в деструкторе или явным вызовом соотв. функции) в CloseHandle передаются INVALID_HANDLE_VALUE. В дебажной версии получаем int3 из ntdll.
6. Вдогонку к 5 — почему то при редиректе если я не указал один из потоков, пытаются использовать соотв. стандартный. А если его нет (приложение-сервис), или я просто НЕ ХОЧУ, чтобы мне гадили в stdout? Дефект дизайна.
7. Сюда же (потамучта редирект). ACE_Pipe реализована .. на сокетах. Аргументация — "дык иначе селект не работает". В топку.
8. В CreateProcess для win32 не используется process name. В результате, невозможно написать одинаковый код для CE и win32. Ау, так что там с портабельностью?
9. Где установка афинити процесса?
10. Нафига хринить PROCESS_INFO, когда можно только хендл процесса. Воообще, такие вещи надо реализовывать стратегиями, определяющими что меня интересует — id процесса, его стартовый поток и т.п. В общем, дефект дизайна.
11. Сколько надо сделать действий, чтобы средиректить вывод процесса? Правильно, ровно столько же, сколько на обычно вин32. А нафига тогда все это? В общем, нужные нормальные инкапсуляции всего этого счастья. Стратегиями редиректа.
12. Корявая реализация — правильно определив функцию запуска процесса, функции дуплицирования хендлов можно получить одинаковую реализацию запуска для posix и win32. Ну или почти одинаковую — сейчас там вообще все раздельно.
13. геттеры и сеттеры называются одинаково, отличаются только количеством параметров и возвращаемым значением. Автору читать stl.
14. Без комментариев:
MAX_COMMAND_LINE_OPTIONS = 128,
ENVIRONMENT_BUFFER = 16 * 1024, // 16K
MAX_ENVIRONMENT_ARGS = 512 //
ACE_Process_Options (int inherit_environment = 1,
int command_line_buf_len = DEFAULT_COMMAND_LINE_BUF_LEN,
int env_buf_len = ENVIRONMENT_BUFFER,
int max_env_args = MAX_ENVIRONMENT_ARGS);

15. И нафига оно в коде вин32?
/// Process-group on Unix; unused on Win32.
pid_t process_group_;
16. Нафига хранить в ACE_Process
/// Set of handles that were passed to the child process.
ACE_Handle_Set handles_passed_;
/// Handle duplicates made for the child process.
ACE_Handle_Set dup_handles_;
Вообще с ними непонятно — нужны ли они на win32, а, скорее всего, это надо определять стратегиями. Я не должен платить за то что не использую.

17. Сейчас ACE_Process_options занимает 8кб, ACE_Process — 2 кб. Я не хочу платить за ненужные мне элементы, это должно настраиваться стратегиями. Либо жить вовне.


Итого:
1. вин32, на мой взгляд писали ламеры.
2. Архитектура -1000.
3. Багов — выше крыши.

И это в паре классов, беглый просмотр. Прикольно, не находите?