Przemek
>Windows programmer have to carefully read MS documentation >and avoid any constructions which can create dead locks or race conditions. You are right on this issue. Now I understand your whole view point. What I could conclude from you analysis is that we need to devise some mechanism to post an event for relevant GT with some data ( as per the nature of event ) which is taken care by the window procedure itself. I think this will solve the whole issue. >From PRG code I should be able to post a simple message as hb_gtInfoEx( pGT, HB_GTI_QUOUE, xSomeData ) and hb_gtInfoEx() unlocks and locks GT as you described. Window procedure retrieves it first-cum-first-server basis and executes the command. Thread issueing this command is only responsible for placing it in the quoue of pGT structure, or even better local GT structure. If this scenario is appropriate, then next question is, when will the Window procedure looks into this quoue, to me it could be WM_IDLE. But above off course is useful where no information is requested, only action is defined to be executed. For any information request we can use hb_mutexSubscribe()/Notify() mechanism. But again it will be an issue at what point of thread execution mutex request is detected and served back. In fact for both opearions, 1) execution an action 2) request of info can be carried in above fashion. Recently I read an article on inter-thread communication but have lost track where it is. For sure inter-thread communication is better over mutex approach. But how it can be achieved, I do not know. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/MT-and-hb_gtInfo%28%29---Appln-Locks-tp20613862p20708951.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
