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

[el es]

On 18-Jun-17 11:20, Juha Manninen via Lazarus wrote:
> On Sat, Jun 17, 2017 at 11:25 PM, el es via Lazarus
> <lazarus at lists.lazarus-ide.org> wrote:
>> But when, during the course of Queue()d callback,
>> I FreeAndNil() the object that had the pointer to the callback procedure, I
>> get SIGSEGV pointing at CheckSynchronize in Application. (address F0F0F0F0).
> 
> I don't know the details of this issue but address F0F0F0F0 means you
> used compiler flag -gt (trash variables) and the variable is
> uninitialized or already freed.
> Yes, the flag -gt is good, helps find such errors.
> 

It came I think, with default build settings in Lazarus 1.6.(2 i think)
I installed recently

> 
>> Hence the question is, how can I know it is safe to free the object,
>> that has the callback subscribed to it?
>> One of the ways would be, to have a flag in that object, that the
>> callback proc will set, and so the thread will know it's now safe to
>> Free(andNil)() it.
> 
> A flag in an uninitialized or freed object does not help.
> 

No, I mean, the callback (executed in main thread context) must not 
indicate that the object is ready to be freed (because the thread 
managing the objects' lifetime may free it before the callback returns).

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);
    // this is what gets executed in the MainForm

   // but then we come back here right ?
   // but then again setting the CanDestruct flag here
   // may be still too early...
   /// so I don't know...
   // unless - may there be any procedure/call I can place in
   // the FSomeObjectNotifyEvent handler, that will cause the
   // execution to NOT come back here? the reverse of 'fork'...
end;

> Juha
> 

Thanks in advance
-L.