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

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

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

Ой, правда?
Может тогда и MS нужно кому-нибудь руки оторвать вот за такой код в winsock2.h:

#ifndef FD_SETSIZE
#define FD_SETSIZE      64
#endif /* FD_SETSIZE */

Ведь ACE сделало у себя тоже самое:

// ---------------- platform features or lack of them -------------

// By default WIN32 has FD_SETSIZE of 64, which places the limit
// between 61 and 64 on the number of clients a server using the
// Select Reactor can support at the same time (i.e., 64 - standard in,
// out, error).  Here we raise the limit to 1024.  Adjust the definition
// below if you need to raise or lower it.

#if !defined (FD_SETSIZE)
#define FD_SETSIZE 1024
#endif /* FD_SETSIZE */

Т.е. и ACE и winsock2.h ожидают, что им кто-нибудь скажет, какова же должна быть размерность FD_SETSIZE. И если никто не говорит, тогда принимают свои собственные решения.

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

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 вообще бы не работал.

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

А вы гляньте в winsock2.h, удивитесь:

/*
 * WinSock 2 extension -- new error codes and type definition
 */

#ifdef WIN32

#define WSAAPI                  FAR PASCAL
#define WSAEVENT                HANDLE

И никуда MS от этого не денется.

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

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

Опаньки! WinAPI не умеет отслеживать, что в WFMO передается больше 64 хендлов? Что-то мне подсказывает, что это далеко не так.
Тем более, что ACE_WFMO_Reactor ограничивает количество хендлов, которые в него можно зарядить:

int
ACE_WFMO_Reactor_Handler_Repository::open (size_t size)
{
  if (size > MAXIMUM_WAIT_OBJECTS)
    ACE_ERROR_RETURN ((LM_ERROR,
                       ACE_LIB_TEXT ("%d exceeds MAXIMUM_WAIT_OBJECTS (%d)\n"),
                       size,
                       MAXIMUM_WAIT_OBJECTS),
                      -1);

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

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

Да уж все дело в ACE -- он так криво написан, что виснет XP. Здорово!

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

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

А смысл есть. Есть люди, которые хотят улучшить ACE.

AS>Например:

За список огромное спасибо.

AS>2. kill не работает.

А чего именно вы ожидали от kill?

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

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

E>Ой, правда?
E>Может тогда и MS нужно кому-нибудь руки оторвать вот за такой код в winsock2.h:
E>Т.е. и ACE и winsock2.h ожидают, что им кто-нибудь скажет, какова же должна быть размерность FD_SETSIZE. И если никто не говорит, тогда принимают свои собственные решения.

Нет. Еще раз. Я меняю FD_SETSIZE на 1024 — винсок работает. А меняю (неявно) на 64 — ACE валится. Т.е. тут проблемы проявляются как раз в ACE, в том, что они используют структуру, зависящую по размеру от этого макроса, прямо в заголовке. Право, ну сколько можно объяснять. Ну не умеют они нормально оформлять код....

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

А вот если приложение не использует ACE, то такой проблемы вообще не возникает. Продолжать?

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

E>А вы гляньте в winsock2.h, удивитесь:
E>И никуда MS от этого не денется.

И что? Сегодня там так, завтра будет другое... Если есть отдельные функции создания, ожидания и сказано использовать их — значит, надо использовать их. Все остальное — предположения о конкретной реализации. Нормальные реализации, которые используют указанные функции, означенных проблем не испытают. А кривые — ну а почему бы и не в топку, как сделали с интерактивными сервисами.

E>Опаньки! WinAPI не умеет отслеживать, что в WFMO передается больше 64 хендлов? Что-то мне подсказывает, что это далеко не так.
E>Тем более, что ACE_WFMO_Reactor ограничивает количество хендлов, которые в него можно зарядить:

Действительно, похоже на то. И тем не менее, факт остается фактом — при использовании WFMO тест полностью вешает систему . Что говорит о качестве тестирования библиотеки, ну и не о наличии в ней багов

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

E>А смысл есть. Есть люди, которые хотят улучшить ACE.

Ну а фигли они это уже ж не сделают? Ведь кривости лежат прямо на поверхности, а либе уже дофига лет... В общем, пустое это. Такую лошадь проще пристрелить, чем пытаться вылечить. У ace глобальные проблемы с архитектурой библиотеки и с написанием кода. Сравнить с той же STLSoft или с Poco.

AS>>2. kill не работает.

E>А чего именно вы ожидали от kill?

Ровно того же, что и в посикс. Хотя для простоты можно было бы ограничиться посылкой сигнала (если консольное приложение) или WM_CLOSE (если GUI), а затем — терминацией. Ну сайте собственно статья есть по поводу.

AS>>Так пусть. Отделите мух от котлет. Ведь никто ж не требует ждать треды, созданные в ace посредством функций поко? Вот и тут — модальный диалог крутит свой цикл, фреймворк — свой. Или вы думаете, что и системный мессадж бокс тоже не будет работать?

E>Сдается мне, что только системный мессадж бокс в такой каше и будет работать.

Нет. Никакой разницы не будет, ужо сколько раз такое было... У нас есть, например, продукт, в котором плагинам дозволено иметь собственные окошки. На чем только их не делали — и на wtl, и на vcl, и на qt... Никаких проблем не возникало И тем более, с компиляцией.

AS>>rw локи — это в качестве примера сложного примитива, где для быстрой реализации необходима подобная функциональность.

E>Т.е. в топку, поскольку есть готовые реализации rwlock-ов.

Ну, скажем так, то, что есть в ace, не выдерживает никакой критики по сравнению с реализацией Рихтера сравните его SWMRG и реализацию в ACE. У него блокировок минимальное количество, тогда как в ACE это все сделано просто ... для отмазки, чтобы былО.

AS>>И не только там — например, критическая секция с таймаутом (привет рихтеру),

E>Т.е. в топку, поскольку критическая секция -- это очень OS-specific. Для портабельности нужно пользоваться mutex-ами для которых есть примитивы ожидания с тайм-аутом.

Угу, вот только тоже не на всех системах. А эмуляция в ACE — зачастую просто отписка.

AS>>лок фри контейнеры и т.п.

E>Вот для этого нужно. Только вот что делать, если не все платформы эту инструкцию поддерживают?

AS>>А в ace просто слажали, неужели так сложно это признать?

E>В ACE, как и в любой другой OpenSource библиотеке, сделали то, что нужно было авторам. Добавить туда swap для ACE_Atomic_Op -- как два байта... Благодоря тому же OpenSource. Просто пока это не нужно было никому. Но раз проблема обозначена, ее явно кто-нибудь решит.

Не верю. Любой, кто пробует написать многопоточное приложение чуть больше хелло ворлд, захочет иметь такую функциональность.

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

D>python я серъезно, у него в стандартной поставке всё это есть, он легкий как пууух + много куда портирован. Вызывать можно хоть из сишного кода.

фигню несёте, весь питонский код выполняется в одной нитке

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

AS>Разыскивается легкий портабельный фреймворк, инкапсулирующий работу с файлами, процессами, потоками, пайпами, синхронизацией. ACE и Poco смотрел, не понравилось — очень много лишнего, ну и банально грязный код .

boost, хотя работы с пайпами там вроде как нет, а в остальном он вам полностью подходит.

AS>>Разыскивается легкий портабельный фреймворк, инкапсулирующий работу с файлами, процессами, потоками, пайпами, синхронизацией. ACE и Poco смотрел, не понравилось — очень много лишнего, ну и банально грязный код .

S>boost, хотя работы с пайпами там вроде как нет, а в остальном он вам полностью подходит.

Буст я смотрел. Как я понял, boost::process до сих пор не принят. Кроме того, в нем довольно мало возможностей. Да и в целом, многопоточность в бусте довольно слабенькая.

Здравствуйте, Sni4ok, Вы писали:
D>>python я серъезно, у него в стандартной поставке всё это есть, он легкий как пууух + много куда портирован. Вызывать можно хоть из сишного кода.
S>фигню несёте, весь питонский код выполняется в одной нитке
Это ты "фигню несёшь". Python может выполняться в любом количестве нитей.
См. доки:
Python Library Reference: 15.2 thread -- Multiple threads of control, 15.3 threading -- Higher-level threading interface
Python/C API Reference Manual: 8. Initialization, Finalization, and Threads

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

AS>>>rw локи — это в качестве примера сложного примитива, где для быстрой реализации необходима подобная функциональность.

E>>Т.е. в топку, поскольку есть готовые реализации rwlock-ов.

AS>Ну, скажем так, то, что есть в ace, не выдерживает никакой критики по сравнению с реализацией Рихтера сравните его SWMRG и реализацию в ACE. У него блокировок минимальное количество, тогда как в ACE это все сделано просто ... для отмазки, чтобы былО.

А реализация Рихтера работает, например, под VxWorks?

AS>>>И не только там — например, критическая секция с таймаутом (привет рихтеру),

E>>Т.е. в топку, поскольку критическая секция -- это очень OS-specific. Для портабельности нужно пользоваться mutex-ами для которых есть примитивы ожидания с тайм-аутом.

AS>Угу, вот только тоже не на всех системах. А эмуляция в ACE — зачастую просто отписка.

Я вот глянул, как реализованы atomic-операции в APR и STLSoft. Уж лучше пользоваться эмуляцией ACE.

AS>>>>rw локи — это в качестве примера сложного примитива, где для быстрой реализации необходима подобная функциональность.

E>>>Т.е. в топку, поскольку есть готовые реализации rwlock-ов.

AS>>Ну, скажем так, то, что есть в ace, не выдерживает никакой критики по сравнению с реализацией Рихтера сравните его SWMRG и реализацию в ACE. У него блокировок минимальное количество, тогда как в ACE это все сделано просто ... для отмазки, чтобы былО.

E>А реализация Рихтера работает, например, под VxWorks?

Если там есть thread_mutex и семафор — безусловно. А если есть готовый системный примитив, то тем более

AS>>Угу, вот только тоже не на всех системах. А эмуляция в ACE — зачастую просто отписка.

E>Я вот глянул, как реализованы atomic-операции в APR и STLSoft. Уж лучше пользоваться эмуляцией ACE.

Чем же лучше? В APR это обычные функции, в STLSoft, как я помню, тоже. Чем же лучше эмуляция ACE, собственно? Тем, что ей неудобно (неочевидно, что на выходе — приходится заглядывать в код, чтобы просто понять, что где вызывается на самом деле, или, например, после += отнимать еще раз результать от выходного long, чтобы получить аналог InterlockedExchangeAdd) пользоваться или тем, что, например, не очень понятно, в каких моментах оно будет работать с interlocked, а в каких — с критической секцией ввиду использования полной специализации (я так понимаю, пример std::vector<bool> ребят ничему не научил)?
На мой взгляд, использование обычных функций просто в РАЗЫ удобнее той поделки, что находится в atomic_op . Опять же, у них все равно есть свои interlocked функции, так почему же не предоставить общественности как обычные функции, так и _легкую_ обертку, которая будет общей для всех и пользовать указанные функции, причем не только для long, но и для других типов такого же размера? И, кстати, куда, интересно, потерялись interlocked функции для поинтеров? Как там в связи с этим поживает x64 платформа?

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

E>>Может тогда и MS нужно кому-нибудь руки оторвать вот за такой код в winsock2.h:
E>>Т.е. и ACE и winsock2.h ожидают, что им кто-нибудь скажет, какова же должна быть размерность FD_SETSIZE. И если никто не говорит, тогда принимают свои собственные решения.

AS>Нет. Еще раз. Я меняю FD_SETSIZE на 1024 — винсок работает. А меняю (неявно) на 64 — ACE валится. Т.е. тут проблемы проявляются как раз в ACE, в том, что они используют структуру, зависящую по размеру от этого макроса, прямо в заголовке. Право, ну сколько можно объяснять. Ну не умеют они нормально оформлять код....

А какой, по вашему мнению, правильный подход в использовании FD_SETSIZE?

E>>>Может тогда и MS нужно кому-нибудь руки оторвать вот за такой код в winsock2.h:
E>>>Т.е. и ACE и winsock2.h ожидают, что им кто-нибудь скажет, какова же должна быть размерность FD_SETSIZE. И если никто не говорит, тогда принимают свои собственные решения.

AS>>Нет. Еще раз. Я меняю FD_SETSIZE на 1024 — винсок работает. А меняю (неявно) на 64 — ACE валится. Т.е. тут проблемы проявляются как раз в ACE, в том, что они используют структуру, зависящую по размеру от этого макроса, прямо в заголовке. Право, ну сколько можно объяснять. Ну не умеют они нормально оформлять код....

E>А какой, по вашему мнению, правильный подход в использовании FD_SETSIZE?

Не использовать его внутри заголовков. Если хочется использовать зависящие от него структуры — использовать указатель на них. Одновременно это позволит еще и уменьшить размер структуры в случае ACE_Process/Options, поскольку в 99.99 случаев ACE_HandleSet просто не используется.
Соответственно, и ACE_HandleSet нуждается в рефакторинге — например, заменить фиксированный набор на вектор.
А вообще, это все, как я уже говорил, должно регулироваться политиками, и весь код этого счастья должен находится в заголовке. За исключением, очевидно, кода, оперирующего fixed_sized arrays. Впрочем, такого кода вообще в общем случае быть не должно, а тут — уж точно.