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
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Reply via email to