Динамически загружаемые bpl , их выгрузка и интерфейсы

Очевидная, но съевшая кучу времени ошибка.

Если в проекте используются динамически загружаемые/выгружаемые bpl, следует помнить, что при выгрузке информации о классах, реализованных в этих bpl в памяти не остается.

Предположим есть некий список, в котором регистрируются _интерфейсы_, имплиментирующие классы которых реализованы в динамически загружаемых bpl(к примеру в плагинах). Сам список живет в базовом приложении, которое и загружает эти пакеты.

Если оставить разрушение этих объектов на совести основного кода, что при использовании интерфейсов довольно очевидно, но делать это _после_ выгрузки bpl с кодом класса реализующего интерфейс, например в секции finalization, - будем получать маловразумительные AV.

Интерфейсы должны быть интерфейсами!

Встретился интересный баг связанные с тем, что смешивается интерфейс и обычный объект. Вернее интерфейс кастрируется до некого альтернативного указателя на экземпляр объекта, без использования замечательного механизма подсчета ссылок.

Есть объект, унаследованный от TComponent и поддерживающий какой-то интерфейс. Временем жизни этого объекта управляет некая фабрика, честно убивающая его при закрытии приложения вручную, как обычный объект - т.е. посредством вызова Free.

А в совершенно другой части приложения есть ссылка на этот объект, но в виде глобальной переменной модуля. Некрасиво, но пока приложение живет проблем нет.

А при завершении работы - фабрика все честно чистит и умирает сама, выполняется весь пользовательский код. И начинают финализироваться модули, обнуляя интерфейсы и соотв. дергая TComponent._Release у давно умершего объекта...

Обнаружить сию неприятность удалось только благодаря FastMM, который заполняет память под разрушенными объектами по специфическому шаблону:

Q: My program used to work fine, but if I enable "FullDebugMode" and run it I get an access violation at address $8080xxxx. Why?
A: You are attempting to access properties of a freed object. When you free a block in "FullDebugMode", FastMM fills the freed memory area with a pattern of $80 bytes. If there were any pointers, long strings or object references inside the freed object they will now point to $80808080 which is in a reserved address space.

Все плохое в FB от Windows :)

Проглядывая презентацию Алексея Пешкова о прошлом, настоящем и будущем безопасности в Firebird наткнулся на интересную информацию:

Тот громкий "зашитый" пароль politically/correct был введен для коннекта сервером к своей базе паролей, которая в свою очередь была введена для порта сервера на .... Win3.X в 92-93г., у которой в то время не было свой подсистемы пользователей.

Как любит говорить один мой друг, коммерческий дух win-платформы пересилил здравый смысл :)

Firebird и база на SSD диске

Встретилось в fb-devel интересное сообщение, о переходе на SSD диск. Если кратко - то значительно увеличилась производительность при большой загрузке дисковой подсистемы, когда основное время тратится на позиционирование головок диска при большом потоке конкурентных обращений.

"Если на обычном 5-то рейде в таких ситуация(более 1000 коннектов) ответ ждали до минуты, то в ssd это время оставалось константным, порядка 4сек."

Естественно не для всяких систем это будет верно, но все же...

Hi Pays,

I can't give you exact figures, but we switched

from
HP 585 4 processor AMD Opteron 850/16GB with raid5 HP SCSI Ultra320 15krpm 8
disk array for the DB

to
HP 385 2 x quad core AMD Opteron 2384 and an FusionIO IODrive, an 80GB SSD
formatted as 40GB so it can continously prepare the remaining 40GB for write
operations which gives it a performance advantage.

The performance gain was noticable. We are btw running FB2.1 classic, AMD 2
x quad core/20GB ram. A "big" query taking around 8 seconds on the SCSI took
only 4 seconds on the FusionIO. Thus the pure performance gain was just
around 2 times faster. It was a query primarily putting load on the disks,
not the CPU, so I guess the new and better server hardware didn't influence
the result too much.

But the really interesting part comes under higher load! As there is no
latency in positioning the heads on a SSD, it really doesn't seem to care
about number of connections (at least not in our case). So where the SCSI
raid dramatically dropped performance and went to around one minute for the
above query during heavy load (>1000 connections), the SSD still answered in
4 seconds. That makes all the difference to us - and not least our users :)

I hope you can use the above informations in your research. Only
disadvantage for the IODrive, at least for now, is that it isn't mounted
until the server loads the drivers for it. So you can't really boot from it.

Kind regards

Poul Dige
Tabulex

Vista и перенаправление(виртуализация) файловой системы

Когда-то, читая замечательный блог Not a kernel guy, встретил у него описание, как 64-х битные версии новых Windows умеют перенаправлять обращения к реестру и файловой системе.

Почитал, удивился и забыл - в тех системах, которые приходилось писать самому или делалось все так, как хочет Майкрософт(пишем только в профиль пользователя), или намеренно указывалась необходимость иметь права на запись в каталог инсталяции для упрощения системы обновлений.

Но впоследнем проекте получилось сполна опробовать красоту решения от MS - пока у пользователя включен UAC, все обращения на запись в ProgramFiles перенаправляются в профиль пользователя(в нашем случае копировалась 400Мб база, лежащая "под" приложением). Казалось бы, сами себе злобные буратины, что не выполняем рекомендации MS. Но раз уж не выполняем, то МС само заботится о нас и на первый взгляд все ок.

До тех пор, пока пользователь, как это принято, не отключает этот UAC к чертовой матери, и оказывается перед девственно чистой БД :)

Одним из способов решения - создание манифеста, в котором указать необходимый приложению объем прав. Хотя и там, с кешированием этих манифестов и прав весело - единожды запустив приложение информация о необходимых ему правах где-то сохраняется, и как ее сбросить я пока не нашел.

Про UAC - http://msdn.microsoft.com/en-us/library/bb756960.aspx
Про манифест - http://msdn.microsoft.com/en-us/library/bb756929.aspx