0002501: Вынести инициализацию меток в фоновый поток

Notes
(0014657) vdemidov (manager) 15-09-2014 19:16	Ну, отдельное окно ИМХО перебор, но закладочку в окно настроек вполне можно добавить.

(0014658) zed (manager) 16-09-2014 05:13	В какое окно настроек? Там где общие настройки программы? Мне кажется это слишком удалённое место и лучше таки кнопочка для быстрого доступа. Да и в глобальных настройках и так уже тесно.

(0014659) zed (manager) 16-09-2014 11:39 edited on: 16-09-2014 11:42	Сделал инициализацию базы в отдельном потоке. Гуй пока никак не блокируется, поэтому вначале он переходит в режим только чтения, а когда метки подгружаются окончательно, включается нормальный режим. Пока не берусь предсказать, что будет с метками, если попробовать добавить метку, во время инициализации. Скорее всего отхватим дубль в id метки, хотя, может и сработает блокировка и ничего страшного не произойдёт. Сейчас зато уже возможно запустить программу, быстро что-то посмотреть и закрыть, не дожидаясь, пока загрузится 100Мб меток :) Теперь как-то нужно делать блокировку и уведомление гуя. Какие будут предложения по реализации?

(0014660) vdemidov (manager) 16-09-2014 13:18	Я бы предпочел, что бы ты не трогал интерфейс IMarkSystemImpl, а реализовал это на уровень выше. Где-то внутри TMarkSystem. То есть, TMarkSystem создает какую-то заглушку IMarkSystemImpl, которая, не умеет ничего, только возвращать, что меток нет и ошибку при добавлении меток. Потом TMarkSystem в отдельном потоке вызывает создание настоящей реализации IMarkSystemImpl, которая указана в настройках. А после окончания инициализации уведомляет, что база изменилась. Пока есть только одна реализация IMarkSystemImpl, то разницы никакой, но если реализаций станет много, то фоновую инициализацию придется добавлять в каждую версию, а если сделать как я предлагаю, то реализации конкретной базы меток, не должны будут заботится об отложенной инициализации - система все сделает за них.

(0014661) zed (manager) 16-09-2014 14:30	А по-моему, всё на своём месте. Ты представь, что изменится BasePath и нужно будет в Changeable создать новое хранилище. А нотифаер-то пришлёт сообщение из гуя и создание опять будет происходить в гуе. Так нам выходит нужно всю реализацию Changeable переносить на уровень выше? И следить за тем, когда прилетит AppStarted тоже придётся в TMarkSystem и за всеми возможными параметрами, что могут появиться у разных БД? Ну, тогда от Changeable можно вообще отказаться, раз все его функции будут уровнем выше.

(0014662) vdemidov (manager) 16-09-2014 14:59	Может это хозяйство стоит и в TMarkSystemImplChangeable запихать. Не знаю. Но то что ему в IMarkSystemImpl не место, я почти уверен. IMarkSystemImpl должно быть максимально простым для реализации нового хранилища меток. Нужно думать как это лучше сделать.

(0014663) zed (manager) 16-09-2014 16:42	Не понял... оно ж и так в TMarkSystemImplChangeable.

(0014664) vdemidov (manager) 20-09-2014 11:54	Я не совсем правильно понял ситуацию (смотрел в браузере на работе), но общая мысль в том что бы не добавлять IMarkSystemImpl тех методов. IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке. А вот Initialize мне не нравится с точки зрения архитектуры. Объект должен полностью инициализироваться в конструкторе и после него должен быть готов для работы. То есть сам вызов конструктора делаем в отдельном потоке, а до его окончания запихиваем nil или какую-то заглушку, которая не умеет ничего делать. А после завершения конструктора заменять на созданное.

(0014665) zed (manager) 20-09-2014 11:58	> IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке. БД на основе SQLite инициализировать не нужно. Зачем же и там испускать поток? Будет только лишний тормоз. > А вот Initialize мне не нравится с точки зрения архитектуры. Объясни тогда как реализовать Changeable по твоей схеме?

(0014666) vdemidov (manager) 20-09-2014 12:13	>> IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке. >БД на основе SQLite инициализировать не нужно. Зачем же и там испускать поток? Будет только лишний тормоз. Ясно, тогда метод нужен, но не в здесь, а в IMarkSystemImplFactory. Такой интерфейс нужно будет сделать, что бы иметь возможность держать несколько разных реализаций. >Объясни тогда как реализовать Changeable по твоей схеме? Ну придется от наследования от текущего родителя TConfigDataElementWithStaticBaseEmptySaveLoad А делать отдельную реализацию, которая при изменении параметров делать примерно то что делается сейчас, только в потоке вызывать не Initialize, а просто сам конструктор.

(0014667) zed (manager) 20-09-2014 12:23	Фишка с Initialize хороша тем, что в процессе можно информировать гуй об этапах инициализации и прерывать её в определённых местах. Ведь объект-то уже есть и с ним можно работать в штатном режиме. С конструктором такого не получится и я не представляю, как можно прервать/отменить создание объекта.

(0014668) vdemidov (manager) 20-09-2014 12:36	Отменить или уведомить гуй можно так же как сейчас делается с операциями с выделенной областью. Просто передавать в фабрику еще и что-то типа IProgressInfo

(0014669) zed (manager) 20-09-2014 14:46	По-моему ты излишне вс усложняешь. У нас есть Changeable интерфейс, что говорит о том, что наш объект изменяем в широком смысле слова - может изменяться как состояние объекта так и его реализация. А ты сюда вносишь ещё какое-то дополнительное требование, что после создания объекта, его состояние уже изменяться не должно. Может тебе просто название метода не нравится? Это же по сути асинхронный AfterConstruction и ничего в нём криминального нету.

(0014670) vdemidov (manager) 20-09-2014 15:46	В том то и дело, что я упрощаю. В моем варианте реализации не нужно задумываться об вызовах методов в процессе инициализации. Ты сам сказал, что не знаешь что произойдет, если кто-то успеет создать метку до окончания инициализации.

(0014671) zed (manager) 21-09-2014 17:06	Ничего не произойдёт - там захватывается WriteLock, так что гуй подвиснет, пока не закончится инициализация. Но эта ситуация вообще говоря существует из-за странного поведения, которое сложилось исторически: если БД открыта в режиме только для чтения (хотя и режим чтения там по-моему никак не проверяется, а проверяется только доступность на запись), в неё всё равно разрешается запись, но с условием, что данные не будут сохранены на диск (внутрях реализации sml нету никаких проверок на ReadWriteState при добавлении или чтении меток). И чтобы гарантировать такое поведение в БД, отличной от SML, нужно будет сильно постараться. Сейчас, пока не закончена инициализация, БД отвечает, что в неё нельзя ни писать ни читать и если ориентироваться на это состояние, то ничего сломать не получится. Хотя, из-за лока на запись оно не поламается и сейчас, но чисто случайно. P.S. А эти фабрики, что ты сейчас добавил вообще зачем? Чисто из-за IsInitializationRequired? Так его ж можно было в конфиг вынести. Хотя, для sml я планировал в конструкторе TMarkSystemSml принимать решение True или False, в зависимости от размера файла меток. Если там несчастные 5 Мб, то инициализацию можно было бы делать синхронной. В подсистеме меток получилось какое-то нереально нагромождение интерфейсов...

(0014679) vdemidov (manager) 07-10-2014 19:40	> P.S. А эти фабрики, что ты сейчас добавил вообще зачем? Что бы иметь возможность выбирать реализацию базы меток и переключать по желанию.

Users who viewed this issue
User List	Anonymous (3589x), ingener (1x), samsomus (1x), vasketsov (1x), gma (1x), zed (1x)
Total Views	3594
Last View	22-11-2024 03:38

Issue History
Date Modified	Username	Field	Change
15-09-2014 18:14	zed	New Issue
15-09-2014 19:16	vdemidov	Note Added: 0014657
16-09-2014 05:13	zed	Note Added: 0014658
16-09-2014 11:39	zed	Note Added: 0014659
16-09-2014 11:39	zed	Assigned To	=> zed
16-09-2014 11:39	zed	Status	new => assigned
16-09-2014 11:40	zed	Target Version	=> 141111
16-09-2014 11:42	zed	Note Edited: 0014659	View Revisions
16-09-2014 13:18	vdemidov	Note Added: 0014660
16-09-2014 14:30	zed	Note Added: 0014661
16-09-2014 14:59	vdemidov	Note Added: 0014662
16-09-2014 16:42	zed	Note Added: 0014663
20-09-2014 11:54	vdemidov	Note Added: 0014664
20-09-2014 11:58	zed	Note Added: 0014665
20-09-2014 12:13	vdemidov	Note Added: 0014666
20-09-2014 12:23	zed	Note Added: 0014667
20-09-2014 12:36	vdemidov	Note Added: 0014668
20-09-2014 14:46	zed	Note Added: 0014669
20-09-2014 15:46	vdemidov	Note Added: 0014670
21-09-2014 17:06	zed	Note Added: 0014671
07-10-2014 19:40	vdemidov	Note Added: 0014679
23-10-2014 09:00	vdemidov	Status	assigned => resolved
23-10-2014 09:00	vdemidov	Fixed in Version	=> 141111
23-10-2014 09:00	vdemidov	Resolution	open => fixed
29-01-2015 17:17	zed	Relationship added	related to 0002615

SASGIS