… пришла в больную голову. ОРЗ или что-то вроде того, блин.
Я тут как-то тут писал что в сетевых пакетах (гоняемых между сервером и клиентом) первым делом нужно указывать их длину.
Ну, чтобы его можно было целиком выбирать пакет из потока без анализа его данных.
Сейчас этого (в FB) нет, и как результат плохо работает отмена выполнения операции (op_cancel).
Еще можно в пакеты включать последовательно генерируемый ID, для более точного управления. Но это так. Мысль не про это.
Мысль про то, что в последнем байте нужно засылать флаг подтверждения завершения отправки пакета. Какие могут быть варианты значений этого флага:
— Ноль, если все ok и пакет таки надо обработать.
— Единица, если пакет нужно выкинуть. К примеру, в процессе его отправки клиент передумал и решил его отменить.
Не знаю, хорошая эта мысль или плохая. Но зафиксировать её стоит.
На сайт загружена новая тестовая сборка IBProvider — v3.55.0.29115.
В неё, в том числе, вошли результаты борьбы с предупреждениями PVS-Studio.
95% это замена assert на assert_hint.
//-V:assert_hint:779, 547
#define assert_hint(cond) assert(cond);
Из этих 95% большая часть — в моей переработанной версии libtommath, которую перед тем как затащить в проект пришлось перетряхнуть и нафаршировать ассертами.
Для остальных 5% пришлось напрячься. (далее…)
Созерцая предупреждение PVS-Studio для код вида:
HRESULT hr=S_OK;
try
{
//.... много страшного кода, которые может кидать исключения, но таки не трогает hr.
assert(hr==S_OK); //PVS-Studio warning: V547 Expression 'hr == ((HRESULT) 0L)' is always true.
}
catch //....
… задумался.
У меня таких декларативных отладочных проверок — даже не вагон и маленькая тележка. Тут их эшелон(ы).
И наверное уже пора добавить в свою в инструментальную библиотеку макрос assert_hint.
С добрым утром.
В процессе обкладывания тестами нового кода IBProvider, обнаружил интересную проблему у плюсового компилятора VS2017 (v15.9.4):
#include <iostream>
void TEST_FUNC(int)
{
std::cout<<"TEST_FUNC(int)"<<std::endl;
}//TEST_FUNC(int)
void TEST_FUNC(short)
{
std::cout<<"TEST_FUNC(short)"<<std::endl;
}//TEST_FUNC(short)
int main()
{
TEST_FUNC(-1i16);
TEST_FUNC((short)-1i16);
TEST_FUNC(1i16);
return 0;
}//main
На выходе видим:
TEST_FUNC(int)
TEST_FUNC(short)
TEST_FUNC(short)
Хотя ожидается:
TEST_FUNC(short)
TEST_FUNC(short)
TEST_FUNC(short)
-1i16 — это же вроде short, а не int.
Вот так вот расслабишься, а оно тебе ключом по голове.
Dmitry Kovalenko on 19 декабря, 2018 | 1 Comment
Я вот думаю, что если эта версия когда и появится, то её основным отличием от v3 будет модульность. В том смысле, что будет набор DLL.
Эта мысль уже неоднократно приходила в мою бестолковую голову, и надо бы её как-то уже задокументировать.
Первым кандидатом на оформление в виде в виде отдельной DLL является менеджер потоков и задач, который продублирован в «LCPI OLE DB Services». Будет интересно посмотреть как эта пара независимых, но работающих совместно, наборов компонент будут разделять общие системные ресурсы.
Пока склоняюсь к тому, что это будут чисто плюсовые библиотеки. То есть, понятное дело, под конкретный компилятор.
Каждый год, 16 декабря, мы с друзьями я себе напоминаю, что не надо обещать сделать то, что уже не готово процентов на 90%. А лучше на все 110%.
И если пообещал, то лучше сделать.
Чтобы потом не было грустно.
—
Вообще, три года назад был интересный месяц — в IBProvider был запилен собственный клиент для Firebird.
Сейчас тоже ничего, но это осознается через пару лет 🙂
Сборки IBProvider v3.54.0.29017 доступы для скачивания из личных кабинетов.
Основные изменения
1. Улучшена устойчивость кода к OUTOFMEMORY.
2. Изменена обработка строки подключения. Дубли и ошибки в структуре списка параметров теперь обрабатываются как критические ситуации и провайдер выкидывает сообщения об ошибках.
До кучи обновлены «LCPI OLEDB Services» — v1.6. Изменения в этих компонентах так же связаны с обработкой строки подключения.
В следующем выпуске IBProvider запланирован переезд на новые конструкции управления OLE DB свойствами. Об старые, которые последний раз обновлялись лет семь назад, начал спотыкаться мозг.
UPD [2018-12-15].
… а к плохим мальчикам и девочкам ночью приходит черный ООМ и убивает все процессы направо и налево
Отсюда
Утром посмотрел состояние сервера после нагрузочного тестирования IBProvider. Что-то как-то много у него дескрипторов осталось незакрытых. 280 штук.
Вроде это уже чинилось и он (сервер) начал нормально себя вести. В частности, после «большого тестирования FB3.0.4.33047» у него оставалось всего 228 дескриптора.
В голову приходят такие мысли:
1. В 3.0.5 что-то сломали?
2. Два из шести проходов нагрузочного тестирования были выполнены с участием 64-битной fbclient.dll. Надо будет её подумать подольше.
3. Да забей. У IBProvider с ресурсами все тип-топ (стучу по столу) и ладно.
Dmitry Kovalenko on 13 декабря, 2018 | 1 Comment
Уже дважды прогонял тесты, позволяющий выпустить релиз IBProvider 3.54, но опять решил немного доработать код 🙂
На днях осознал «variadic templates», и не смог не заюзать их для обновления одной штуки, написанной в далеком 2001 году — это конструкция для хранения указателя на метод объекта. Аналог event’ов из Delphi и C++ Builder.
Код радикально сократился и теперь может переваривать методы с любым количеством параметров. Немного расстроило то, что поддержка variadic template появилась только в 2013 студии. Поэтому новый код работает только в сборках vc12xp, vc14xp и vc15. Сборки vc10, vc11xp используют старые конструкции (хотя я их тоже доработал для поддержки rvalue references). В триал включены сборки vc12xp.
Если кому интересно — исходный код обозначенных конструкций можно посмотреть в каталоге «c:\Program Files (x86)\LCPI\IBProvider.3\lib\structure\closure».
Вообще, современные плюсы немного «сдвигают» сознание. Каких-то десять лет назад о такой штуке как «variadic templates» даже и не мечталось.
— У тебя есть мечта?
— Да, все переписать.
— Ну так перепиши!
— А как я без мечты буду жить?!
