Anonymous | Login | Signup for a new account | 08-05-24 14:49 UTC | ![]() |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002224 | SAS.Планета | Рефакторинг | public | 24-10-2013 10:50 | 08-01-2014 16:56 | ||||
Reporter | vdemidov | ||||||||
Assigned To | zed | ||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 121010 | ||||||||
Target Version | 140303 | Fixed in Version | 140303 | ||||||
Summary | 0002224: Убрать создание отдельного INotifier для каждого запроса на закачку тайла | ||||||||
Description | Сейчас для каждого запроса на закачку тайла создается отдельный нотифаер, а это достаточно дорогой объект с примитивом синхронизации. Вполне реально сделать пул нотифаеров в подсистеме закачки и использовать их по очереди. Возможно два варианта: 1. Как и сейчас считать что если мы подписались на нотифаер запроса на закачку и пришло уведомление, то значит запрос выполнен, не обращая внимамание на сообщение в запросе. Тогда нельзя использовать один нотифаер в нескольких закачках. 2. При получении уведомления от нотифаера проверять наш ли запрос выполился и если не наш, то продолжать ждать следующего. Тогда можно ограничиться даже одним нотифаером. Мне этот вариант нравится больше. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
![]() |
||||||
|
![]() |
|
(0013504) zed (manager) 08-01-2014 04:42 |
Вариант 3: использовать обычный CallBack. Тем более, что сейчас этот нотифаер так и используется - у него всегда один листнер и он в том же классе, который создаёт нотифаера. Таким образом, передав в конструктор TTileRequestTask наш коллбэк, получим профит в простоте реализации (без пула) и отсутствии оверхэда на примитивах синхронизации. |
(0013506) zed (manager) 08-01-2014 05:35 |
Ещё плюсом будет то, что в коллбэке можно будет передать сразу 2 параметра: ITileRequestTask (Self) и ITileRequestResult из-за чего мы cможем смело прибить метод TTileRequestTask.GetResult и избавиться от ещё одной синхронизации. |
(0013508) vdemidov (manager) 08-01-2014 07:44 |
Может и так. Только нужно внимательно смотреть, за подсчетом ссылок и за временем жизни, а то могут быть очень веселые эффекты. Плюс в качестве CallBack нужно будет объявлять или отдельный интерфейс, или делать простую функцию, а объект передавать через обычный указатель (procedure of object в интерфейсе качалки использовать очень не хочется, что бы не привязываться к делфовским типам) |
(0013513) zed (manager) 08-01-2014 10:25 |
> procedure of object в интерфейсе качалки использовать очень не хочется А интерфейса качалки оно и не коснётся. Качалка вызывает метод ITileRequestTaskInternal.SetFinished(const AResult: ITileRequestResult) |
(0013529) zed (manager) 08-01-2014 16:54 |
Да, пришлось таки коллбэк обернуть в интерфейс. И ещё попутный момент: а почему в этом же TTileRequestTask для отмены операции используется именно INotifierOneOperation, а не обычный INotifierOperation? Там же тоже оверхэд появляется на каждый запрос. |
![]() |
|||
Date Modified | Username | Field | Change |
24-10-2013 10:50 | vdemidov | New Issue | |
24-10-2013 10:51 | vdemidov | Status | new => confirmed |
24-10-2013 10:51 | vdemidov | Relationship added | parent of 0002223 |
04-11-2013 14:22 | vdemidov | Target Version | 24xxxx => 140303 |
08-01-2014 04:42 | zed | Note Added: 0013504 | |
08-01-2014 05:35 | zed | Note Added: 0013506 | |
08-01-2014 07:44 | vdemidov | Note Added: 0013508 | |
08-01-2014 10:25 | zed | Note Added: 0013513 | |
08-01-2014 16:54 | zed | Note Added: 0013529 | |
08-01-2014 16:56 | zed | Relationship replaced | related to 0002223 |
08-01-2014 16:56 | zed | Status | confirmed => resolved |
08-01-2014 16:56 | zed | Fixed in Version | => 140303 |
08-01-2014 16:56 | zed | Resolution | open => fixed |
08-01-2014 16:56 | zed | Assigned To | => zed |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |