View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002501 | SAS.Планета | Рефакторинг / Refactoring | public | 15-09-2014 18:14 | 23-10-2014 09:00 |
| Reporter | zed | Assigned To | zed | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 140505 | ||||
| Target Version | 141111 | Fixed in Version | 141111 | ||
| Summary | 0002501: Вынести инициализацию меток в фоновый поток | ||||
| Description | Сейчас подсистема меток инициализируется из главного потока программы, что приводит к замораживанию интерфейса, пока метки не будут готовы к работе (при большом количестве меток инициализация может занимать несколько секунд). Нужно изменить это поведение: вынести инициализацию в фоновый поток, в гуе завести нотифаер в который передавать события об изменении состояния базы меток, а в базе меток завести ещё одно состояние: "идёт инициализация". На время инициализации, в гуе надо запретить создавать метки и вообще открывать менеджер меток. Можно визуально "засерить" соответствующие кнопки на панели инструментов. Ну и наконец, нужно добавить кнопку, по которой открывать окошко "Настройка базы меток", где отображать состояние базы (инициализация/открыта только для чтения/открыта на запись) и всевозможные настройки. Из этого окошка должна быть возможность прервать инициализацию, закрыть открытую базу и открыть её в другой папке (переключение активной БД налету) и проч. Если появятся другие типы баз меток, кроме sml, в этом же окошке нужно отображать и их настройки. Ну, в общем, в дополнение к менеджеру меток, нужен менеджер баз меток. | ||||
| Tags | No tags attached. | ||||
|
|
Ну, отдельное окно ИМХО перебор, но закладочку в окно настроек вполне можно добавить. |
|
|
В какое окно настроек? Там где общие настройки программы? Мне кажется это слишком удалённое место и лучше таки кнопочка для быстрого доступа. Да и в глобальных настройках и так уже тесно. |
|
|
Сделал инициализацию базы в отдельном потоке. Гуй пока никак не блокируется, поэтому вначале он переходит в режим только чтения, а когда метки подгружаются окончательно, включается нормальный режим. Пока не берусь предсказать, что будет с метками, если попробовать добавить метку, во время инициализации. Скорее всего отхватим дубль в id метки, хотя, может и сработает блокировка и ничего страшного не произойдёт. Сейчас зато уже возможно запустить программу, быстро что-то посмотреть и закрыть, не дожидаясь, пока загрузится 100Мб меток :) Теперь как-то нужно делать блокировку и уведомление гуя. Какие будут предложения по реализации? |
|
|
Я бы предпочел, что бы ты не трогал интерфейс IMarkSystemImpl, а реализовал это на уровень выше. Где-то внутри TMarkSystem. То есть, TMarkSystem создает какую-то заглушку IMarkSystemImpl, которая, не умеет ничего, только возвращать, что меток нет и ошибку при добавлении меток. Потом TMarkSystem в отдельном потоке вызывает создание настоящей реализации IMarkSystemImpl, которая указана в настройках. А после окончания инициализации уведомляет, что база изменилась. Пока есть только одна реализация IMarkSystemImpl, то разницы никакой, но если реализаций станет много, то фоновую инициализацию придется добавлять в каждую версию, а если сделать как я предлагаю, то реализации конкретной базы меток, не должны будут заботится об отложенной инициализации - система все сделает за них. |
|
|
А по-моему, всё на своём месте. Ты представь, что изменится BasePath и нужно будет в Changeable создать новое хранилище. А нотифаер-то пришлёт сообщение из гуя и создание опять будет происходить в гуе. Так нам выходит нужно всю реализацию Changeable переносить на уровень выше? И следить за тем, когда прилетит AppStarted тоже придётся в TMarkSystem и за всеми возможными параметрами, что могут появиться у разных БД? Ну, тогда от Changeable можно вообще отказаться, раз все его функции будут уровнем выше. |
|
|
Может это хозяйство стоит и в TMarkSystemImplChangeable запихать. Не знаю. Но то что ему в IMarkSystemImpl не место, я почти уверен. IMarkSystemImpl должно быть максимально простым для реализации нового хранилища меток. Нужно думать как это лучше сделать. |
|
|
Не понял... оно ж и так в TMarkSystemImplChangeable. |
|
|
Я не совсем правильно понял ситуацию (смотрел в браузере на работе), но общая мысль в том что бы не добавлять IMarkSystemImpl тех методов. IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке. А вот Initialize мне не нравится с точки зрения архитектуры. Объект должен полностью инициализироваться в конструкторе и после него должен быть готов для работы. То есть сам вызов конструктора делаем в отдельном потоке, а до его окончания запихиваем nil или какую-то заглушку, которая не умеет ничего делать. А после завершения конструктора заменять на созданное. |
|
|
> IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке. БД на основе SQLite инициализировать не нужно. Зачем же и там испускать поток? Будет только лишний тормоз. > А вот Initialize мне не нравится с точки зрения архитектуры. Объясни тогда как реализовать Changeable по твоей схеме? |
|
|
>> IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке. >БД на основе SQLite инициализировать не нужно. Зачем же и там испускать поток? Будет только лишний тормоз. Ясно, тогда метод нужен, но не в здесь, а в IMarkSystemImplFactory. Такой интерфейс нужно будет сделать, что бы иметь возможность держать несколько разных реализаций. >Объясни тогда как реализовать Changeable по твоей схеме? Ну придется от наследования от текущего родителя TConfigDataElementWithStaticBaseEmptySaveLoad А делать отдельную реализацию, которая при изменении параметров делать примерно то что делается сейчас, только в потоке вызывать не Initialize, а просто сам конструктор. |
|
|
Фишка с Initialize хороша тем, что в процессе можно информировать гуй об этапах инициализации и прерывать её в определённых местах. Ведь объект-то уже есть и с ним можно работать в штатном режиме. С конструктором такого не получится и я не представляю, как можно прервать/отменить создание объекта. |
|
|
Отменить или уведомить гуй можно так же как сейчас делается с операциями с выделенной областью. Просто передавать в фабрику еще и что-то типа IProgressInfo |
|
|
По-моему ты излишне вс усложняешь. У нас есть Changeable интерфейс, что говорит о том, что наш объект изменяем в широком смысле слова - может изменяться как состояние объекта так и его реализация. А ты сюда вносишь ещё какое-то дополнительное требование, что после создания объекта, его состояние уже изменяться не должно. Может тебе просто название метода не нравится? Это же по сути асинхронный AfterConstruction и ничего в нём криминального нету. |
|
|
В том то и дело, что я упрощаю. В моем варианте реализации не нужно задумываться об вызовах методов в процессе инициализации. Ты сам сказал, что не знаешь что произойдет, если кто-то успеет создать метку до окончания инициализации. |
|
|
Ничего не произойдёт - там захватывается WriteLock, так что гуй подвиснет, пока не закончится инициализация. Но эта ситуация вообще говоря существует из-за странного поведения, которое сложилось исторически: если БД открыта в режиме только для чтения (хотя и режим чтения там по-моему никак не проверяется, а проверяется только доступность на запись), в неё всё равно разрешается запись, но с условием, что данные не будут сохранены на диск (внутрях реализации sml нету никаких проверок на ReadWriteState при добавлении или чтении меток). И чтобы гарантировать такое поведение в БД, отличной от SML, нужно будет сильно постараться. Сейчас, пока не закончена инициализация, БД отвечает, что в неё нельзя ни писать ни читать и если ориентироваться на это состояние, то ничего сломать не получится. Хотя, из-за лока на запись оно не поламается и сейчас, но чисто случайно. P.S. А эти фабрики, что ты сейчас добавил вообще зачем? Чисто из-за IsInitializationRequired? Так его ж можно было в конфиг вынести. Хотя, для sml я планировал в конструкторе TMarkSystemSml принимать решение True или False, в зависимости от размера файла меток. Если там несчастные 5 Мб, то инициализацию можно было бы делать синхронной. В подсистеме меток получилось какое-то нереально нагромождение интерфейсов... |
|
|
> P.S. А эти фабрики, что ты сейчас добавил вообще зачем? Что бы иметь возможность выбирать реализацию базы меток и переключать по желанию. |
| 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 | |
| 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 |
| 08-08-2025 13:25 | zed | Category | Рефакторинг => Рефакторинг / Refactoring |