On 19/06/17 00:30, José Mejuto via Lazarus wrote:
> El 18/06/2017 a las 22:44, el es via Lazarus escribió:
>
>> Hence the object, would have to have ITS callback routine be something like
>> a TNotifyEvent ( procedure(AObject: TSomeObject) of object, or something),
>> and the flag set is set when the callback returns to the object context like
>>
>> procedure TSomeObject.Callback;
>> // this procedure is enQueue()d by the thread
>> begin
>> if Assigned({Self.}FSomeObjectNotifyEvent) then
>> FSomeObjectNotifyEvent(Self);
>
> Hello,
>
> Just exit the procedure and there is not free problem. You will get an
> exception when you use object data, not object code.
>
I did now, and also, beforehands I did not have the TSomeObjectNotifyEvent()
type of callback...
so in the callback I had to browse through the list of TSomeObject's, searching
for the right one - and that was really risky;
>
> procedure TSomeObject.Callback;
> // this procedure is enQueue()d by the thread
> begin
> if Assigned({Self.}FSomeObjectNotifyEvent) then
> FSomeObjectNotifyEvent(Self);
> Self.CanBeDestroyed := true;
> Exit;
> end;
>
> After you set CanBeDestroyed to true you must consider all data as RANDOM, so
> don't access any property or variable.
>
Understood, I ensured there is nothing accessing the TSomeObject sent as Self
to the event handler, after it comes back.
> Remember that creating and destroying threads is very expensive in CPU time.
>
There is only 2 statically defined threads in the entire application :)
one is the GUI thread (the Application, aka main thread)
and the other is the TSomeObject life handler
(you could call it a queue of objects to be processed and returning results
from hardware communication)
Thanks,
-L.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus-ide.org/listinfo/lazarus
