SASGIS - SAS.Планета
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002224SAS.ПланетаРефакторингpublic24-10-2013 10:5008-01-2014 16:56
Reportervdemidov 
Assigned Tozed 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version121010 
Target Version140303Fixed in Version140303 
Summary0002224: Убрать создание отдельного INotifier для каждого запроса на закачку тайла
DescriptionСейчас для каждого запроса на закачку тайла создается отдельный нотифаер, а это достаточно дорогой объект с примитивом синхронизации. Вполне реально сделать пул нотифаеров в подсистеме закачки и использовать их по очереди. Возможно два варианта:
1. Как и сейчас считать что если мы подписались на нотифаер запроса на закачку и пришло уведомление, то значит запрос выполнен, не обращая внимамание на сообщение в запросе. Тогда нельзя использовать один нотифаер в нескольких закачках.
2. При получении уведомления от нотифаера проверять наш ли запрос выполился и если не наш, то продолжать ждать следующего. Тогда можно ограничиться даже одним нотифаером. Мне этот вариант нравится больше.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002223confirmed  Переделать закачку видимой области карты 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-10-2013 10:50vdemidovNew Issue
24-10-2013 10:51vdemidovStatusnew => confirmed
24-10-2013 10:51vdemidovRelationship addedparent of 0002223
04-11-2013 14:22vdemidovTarget Version24xxxx => 140303
08-01-2014 04:42zedNote Added: 0013504
08-01-2014 05:35zedNote Added: 0013506
08-01-2014 07:44vdemidovNote Added: 0013508
08-01-2014 10:25zedNote Added: 0013513
08-01-2014 16:54zedNote Added: 0013529
08-01-2014 16:56zedRelationship replacedrelated to 0002223
08-01-2014 16:56zedStatusconfirmed => resolved
08-01-2014 16:56zedFixed in Version => 140303
08-01-2014 16:56zedResolutionopen => fixed
08-01-2014 16:56zedAssigned To => zed

Notes
(0013504)
zed   
08-01-2014 04:42   
Вариант 3: использовать обычный CallBack. Тем более, что сейчас этот нотифаер так и используется - у него всегда один листнер и он в том же классе, который создаёт нотифаера. Таким образом, передав в конструктор TTileRequestTask наш коллбэк, получим профит в простоте реализации (без пула) и отсутствии оверхэда на примитивах синхронизации.
(0013506)
zed   
08-01-2014 05:35   
Ещё плюсом будет то, что в коллбэке можно будет передать сразу 2 параметра: ITileRequestTask (Self) и ITileRequestResult из-за чего мы cможем смело прибить метод TTileRequestTask.GetResult и избавиться от ещё одной синхронизации.
(0013508)
vdemidov   
08-01-2014 07:44   
Может и так. Только нужно внимательно смотреть, за подсчетом ссылок и за временем жизни, а то могут быть очень веселые эффекты. Плюс в качестве CallBack нужно будет объявлять или отдельный интерфейс, или делать простую функцию, а объект передавать через обычный указатель (procedure of object в интерфейсе качалки использовать очень не хочется, что бы не привязываться к делфовским типам)
(0013513)
zed   
08-01-2014 10:25   
> procedure of object в интерфейсе качалки использовать очень не хочется
А интерфейса качалки оно и не коснётся. Качалка вызывает метод
ITileRequestTaskInternal.SetFinished(const AResult: ITileRequestResult)
(0013529)
zed   
08-01-2014 16:54   
Да, пришлось таки коллбэк обернуть в интерфейс.

И ещё попутный момент: а почему в этом же TTileRequestTask для отмены операции используется именно INotifierOneOperation, а не обычный INotifierOperation? Там же тоже оверхэд появляется на каждый запрос.