Related to the previous message, does Async capture everything about
the parameters?

procedure Demo;
var
MyList : TStringList;
begin
MyList := TStringList.Create;

MyList.Add("Hello");
MyList.Add("Mum");
async ProcessList(MyList);
MyList.Free;
end;


Is that going to work? Or will MyList be empty or invalid when it gets
to ProcessList?

(It would be good to have the answer to this in the documentation I
think - to make clear the implications either way.)

--

Matthew Jones

Matthew Jones wrote:

>  Or will MyList be empty or invalid when it gets
> to ProcessList?

I'd really like to know the proper answer to this.

--

Matthew Jones

On 9/23/2016 8:55 AM, Matthew Jones wrote:
> Matthew Jones wrote:
>
>>  Or will MyList be empty or invalid when it gets
>> to ProcessList?
>
> I'd really like to know the proper answer to this.

I would say technically it is invalid.

In EWB async queues up the the function call next time event loop runs
so your Demo function actually continues and completes - including
calling Mylist.Free before the "ProcessList(MyList)" is executed. So you
just passed in an invalid object.

In reality Java uses garbage collection so the MyList might actually be
valid still and simply appear as empty - however IMHO if it works and
shows empty list then that's a curious incident and not expected behavior.

Internally async uses javascript settimeout with expression as anonymous
function and i don't know enough internals of JS to tell you what is
exactly does.

However i would say that with the code you have shown you're looking for
trouble and might end up with weird bugs

Raul

Raul wrote:

> I would say technically it is invalid.

Interesting. I thought the idea was that these things captured the
state of everything, or is it just the parameters? I should do a proper
test shouldn't I - can't be hard to set up.

--

Matthew Jones

On 9/26/2016 3:49 AM, Matthew Jones wrote:
> Interesting. I thought the idea was that these things captured the
> state of everything, or is it just the parameters? I should do a proper
> test shouldn't I - can't be hard to set up.

Curious - what made you think that (captures state) ?

It's really just a (anonymous) function call that is executed when timer
expires so unless javascript does some extra magic there with scope or
such  (i don't think it does) dynamically allocated objects will be a
problem since other code can change the underlying object.

Raul

Raul wrote:

> Curious - what made you think that (captures state) ?

The help:
"Also, asynchronous calls are emitted by the compiler as Javascript
closures. Closures are functions that are dynamically created and
capture the entire run-time scope of their parent execution context."

--

Matthew Jones

On 9/26/2016 10:23 AM, Matthew Jones wrote:
> "Also, asynchronous calls are emitted by the compiler as Javascript
> closures. Closures are functions that are dynamically created and
> capture the entire run-time scope of their parent execution context."

I believe it's same as this :
https://developer.mozilla.org/en/docs/Web/JavaScript/Closures

We need Tim here but my opinion is that this should be looked as pointers

closure captures the state of your MyList variable but it would simply
capture the address that the dynamic obejct points to (and not the
content of the dynamic object).

Obviously the code you had is even more complex since you're actually
freeing the dynamic object
 async ProcessList(MyList);
 MyList.Free;

So i'm not sure what the closure captured exactly. Hence my comment that
assuming closure captured the object address it might see empty list
(but doing those is a side effect of memory not being collected and
reused - which in real app might happen).

Now i'm curious as well and when i have some time will run some tests to
see that actualyl happens.

Raul

Raul,

<< We need Tim here but my opinion is that this should be looked as pointers >>

You are correct.  Yes, it will capture the instance reference at the time of the creation of the closure, but it cannot possibly ensure that something else doesn't call the Free method on the instance and wipe out all member variables that are enclosed within the instance (EWB sets them to their "empty" state, so strings are blank, numbers are 0, and references are nil).  The JS garbage collector will ensure that the reference itself sticks around, but not the contents within once EWB does its Free business, which means that any references contained in member variables could be gone.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Yes, it will capture the instance reference at the time of the
> creation of the closure, but it cannot possibly ensure that something
> else doesn't call the Free method on the instance

Thanks. Good to be completely sure. Assume safety is needed.

--

Matthew Jones