Ok, I did not notice that exists method TApplication.RemoveAsyncCalls(const AnObject: TObject). Anyway it's strange that AnObject param is compared to Data param from QueueAsyncCall, not to AMethod, but this is not a problem.
2011/6/8 Krzysztof <[email protected]> > Ok, this can be done with critical section but what with AV scenario? > Example: > 1. Thread add queue calling Application.QueueAsyncCall(MyObj.EventMethod, > 0); > 2. MyObj is destroyed by main thread > 3. Main thread process messages and try call queue added by thread but > reference to MyObj.EventMethod was destroyed by previous message loop. This > cause Access Violation. > > I could remove this queue in MyObj destructor but TApplication.FAsyncCall > is in private section :/ > > 2011/6/8 Henry Vermaak <[email protected]> > >> On 08/06/11 16:28, Krzysztof wrote: >> >>> Hm, I forgot about Application.QueueAsyncCall. And this can be safely >>> call from thread without TThread.Synchronize() ? Because I don't want >>> use Synchronize() in any part of thread code. So this is correct code? : >>> >>> procedure TMyThread.Execute; >>> begin >>> // <some code here> >>> Application.QueueAsyncCall(@SomeObj.TestMethod, PtrInt(NewStr('Some >>> value'))); >>> // <some code here> >>> end; >>> >>> There is no chance for deadlock with main thread calling this from >>> inside another thread? >>> >> >> You have to protect it with a critical section (if you have more than one >> thread calling QueueAsyncCall). >> >> Henry >> >> >> -- >> _______________________________________________ >> Lazarus mailing list >> [email protected] >> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus >> >> >
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
