[Lazarus] Enqueuing a callback from a thread via other class - or am I overcomplicating this ?

[Lukasz Sokol]

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.