|
Тема
|
поредица от HTTP requests
|
|
Автор | longy (Нерегистриран) |
Публикувано | 19.06.07 08:34 |
|
Дайте съвет моля.
При дадени събития от UI-то (clicks, timers etc.) искам да изпращам http request към сървър и после да обработвам responce и да update-вам UI-то по подходящ начин.
Обаче понеже не знам колко време ще отнеме обработката на даден request, пък и доколкото съм наясно сървъра обработва всеки request в отделен процес (или поне отделен thread) не е гарантирано, че ще получа responce-ите в същия ред, в който съм изпратил request-ите.
Преди да се сблъскам с този проблем бях направил така:
При събитие от UI-то стартирах отделен thread, който изпращаше request и получаваше responce и после на OnTerminate() предаваше получените данни към UI-то. Така се спасявах от замръзването на UI-то в случай на забавяне в комуникацията.
Обаче ми се случи точно това, което описах като проблем по-горе:
получих response от по-късно изпратен request преди да съм получил от по-рано изпратения и това страшно ми обърка работата.
мисля, че стандартно решение на такива проблеми е ползването на опашка, в която се добавя request при дадено събитие от UI-то и един thread, който чете от опашката поредния request, изпраща го и получава responce.
Това, за което имам нужда от съвет е следното:
- да кажем че communication thread-a е получил вече responce от сървъра и искам да прехвърля данните към UI-то.
как да си гарантирам, че това "прехвърляне" на данните към UI-то ще завърши (правя доста анализи на получените, данни, още повече че става въпрос за HTTP комуникация, така че има парсване и може да отнеме време)
преди communication thread-a да изпълни следващия request от опашката и да "замаже" получения responce с нови данни ?
| |
Тема
|
Ами направи опашка и на получените
[re: longy]
|
|
Автор |
NikB (любопитен) |
Публикувано | 20.06.07 08:17 |
|
Ами направи опашка и на получените.
Впрочем, ако в комуникационната си нишка създадеш обект с отговора и го постнеш (PostMessage) към "UI"-то си (след което нишката се заема със следващата комуникация), отговорите ще пристигат по ред.
| |
|
Това за поредността на получаване на PostMessage-тата всъщност не е гарантирано. Доскоро и аз си мислех така, но докато се ровехме тука с колегите из сайта за разработчици на Wine (баси мамата тия пичове са абсолютни изроди) разбрахме, че всъщност опашката със съобщенията на Windows е асинхронна. Т.е. Windows не ти гарантира, че съобщенията ще се получат в същия ред, в който си ги изпратил. И това обясни един много странен бъг, от който клиентите ни се оплакват по веднъж на всеки 3-4 месеца вече повече от 3 години
Това, което искам да кажа е, че може би ще е по-добре да използваш нещо от сортна на TThreadList (или какъв да е list плюс някакъв механизъм за синхронизация), който го ползваш като опашка - от едната нишка му добавяш елементи в края, а от другата ги четеш от началото.
| |
|
Това за PostMessage е много важно - а ясно ли е от къде се получава асинхронноста?
До сега си мислех, че ако не се ползват допълнителни Application.Process.Message (или подобни техники), че синхронността е гарантирана.
| |
|
Ами да ти кажа честно - не съм много сигурен. Мисля, че например ако ти е натоварена системата Windows може да реши да "оптимизира" опашката със съобщенията и да ги размести. Ама не мога да ти кажа точно кога и при какви условия става. Знам само, че вече не мога да разчитам на последователното им получаване
PS Мразя dir.bg
| |
|
>> Това за поредността на получаване на PostMessage-тата всъщност не е гарантирано.
Ъхъ, но затова има SendMessage()
| |
|
Да, ама SendMessage, както много добре знаеш, не приключва, докато не се обработи съобщението. И през цялото това време нишката седи и чака. И каква е файдата тогава от нишката? Не мисля, че това е идеята...
| |
|
Нямам предвид конкретния случай. SendMessage() наистина чака докато се обработи съобщението. Интересното е, че за нишките има ф-я PostThreadMessage(), но няма аналогична ф-я SendThreadMessage() .
| |
Тема
|
синхронизация?
[re: longy]
|
|
Автор | Йopдaн (Нерегистриран) |
Публикувано | 23.06.07 02:21 |
|
Не става ли дума за стандартния случай, който изисква синхронизация?
Нишка N изпраща данни, получава, и тука чака нишка N-1, и после продължава с промяна на UI-то.
| |
|
|
|
|