Дайте съвет моля.

При дадени събития от 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 с нови данни ?

Ами направи опашка и на получените.
Впрочем, ако в комуникационната си нишка създадеш обект с отговора и го постнеш (PostMessage) към "UI"-то си (след което нишката се заема със следващата комуникация), отговорите ще пристигат по ред.

Съдържаниет е скрито
Влезте за да го видите

Това за поредността на получаване на PostMessage-тата всъщност не е гарантирано. Доскоро и аз си мислех така, но докато се ровехме тука с колегите из сайта за разработчици на Wine (баси мамата тия пичове са абсолютни изроди) разбрахме, че всъщност опашката със съобщенията на Windows е асинхронна. Т.е. Windows не ти гарантира, че съобщенията ще се получат в същия ред, в който си ги изпратил. И това обясни един много странен бъг, от който клиентите ни се оплакват по веднъж на всеки 3-4 месеца вече повече от 3 години

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Това за PostMessage е много важно - а ясно ли е от къде се получава асинхронноста?
До сега си мислех, че ако не се ползват допълнителни Application.Process.Message (или подобни техники), че синхронността е гарантирана.

Съдържаниет е скрито
Влезте за да го видите

Ами да ти кажа честно - не съм много сигурен. Мисля, че например ако ти е натоварена системата Windows може да реши да "оптимизира" опашката със съобщенията и да ги размести. Ама не мога да ти кажа точно кога и при какви условия става. Знам само, че вече не мога да разчитам на последователното им получаване

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

>> Това за поредността на получаване на PostMessage-тата всъщност не е гарантирано.

Ъхъ, но затова има SendMessage()

Да, ама SendMessage, както много добре знаеш, не приключва, докато не се обработи съобщението. И през цялото това време нишката седи и чака. И каква е файдата тогава от нишката?

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Нямам предвид конкретния случай. SendMessage() наистина чака докато се обработи съобщението. Интересното е, че за нишките има ф-я PostThreadMessage(), но няма аналогична ф-я SendThreadMessage() .

Не става ли дума за стандартния случай, който изисква синхронизация?
Нишка N изпраща данни, получава, и тука чака нишка N-1, и после продължава с промяна на UI-то.