View mode: basic / threaded / horizontal-split · Log in · Help
April 07, 2005
Re: new thread with nested function
From reading the issues, it appears the problem is delegates are just a 
way of referencing local variables where the function was called rather 
than true closures.

For those interested, true closures allow a function to 'capture' values 
at the time the function is created(not declared), and the values it 
takes along with it are called upvalues.

A nice example of this is Paul Grahams challenge to create an accumulator:

http://store.yahoo.com/paulgraham/accgen.html

Which is possible with classes and templates, but it fairly messy.

Lua properly handles upvalues, its design is quite interesting:

http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/sblp2005.pdf

-David


Sean Kelly wrote:

> In article <opsou4v7p323k2f5@nrage.netwin.co.nz>, Regan Heath says...
> 
>>I forgot to mention. This example was actually my test to see what happens  
>>with structs vs classes. What I was trying to answer was:
>>
>>1. does passing a struct delegate to a thread stop the struct from being  
>>free'd.
>>2. does passing a class delegate to a thread stop the class from being  
>>free'd.
>>
>>The answer to #1 seems to be no. No surprises really, it's a value type  
>>stored on the stack, not a reference.
> 
> 
> Right.
> 
> 
>>I wasn't sure I had answered #2, to be sure I added a fullCollect (see  
>>code below).
>>
>>It appears passing a class delegate, prevents the class from being free'd,  
>>which is good, I wondered whether the delegate pointer would do that, or  
>>if it had been overlooked.
> 
> 
> Right.  Any GCed object won't be cleaned up until all references to it are gone.
> The thread these references are held in is not an issue.
> 
> 
> Sean
> 
>
April 07, 2005
Re: new thread with nested function
In article <opsovvsbcn23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Thu, 07 Apr 2005 09:52:28 -0700, Russ Lewis  
><spamhole-2001-07-16@deming-os.org> wrote:
>> If you allocated the struct on the stack, then it should not be GC'd  
>> until the delegate goes away.
>
>So, you think I have found a bug below?

I would expect your sample code to (probably) output:

5
6

At this point the app may print something and it may just explode, as I expect
'a' would have gone out of scope.  Best case would be for it to print 6 twice
more and either 5, 0, or something random for the other two lines.  But none of
this is guaranteed, since nothing says the new threads will actually start in
the 1 second before fire() exits.


Sean
April 07, 2005
Re: new thread with nested function
In article <d34eoo$t6m$1@digitaldaemon.com>, David Medlock says...
>
> From reading the issues, it appears the problem is delegates are just a 
>way of referencing local variables where the function was called rather 
>than true closures.

They are.  True closures have been discussed but are not currently a part of D.


Sean
April 07, 2005
Re: new thread with nested function
Right.  I have been an advocate of being able to copy the stack 
variables onto the heap, so that you can create (something like?) true 
closures.  It hasn't gotten in, yet.

I was just thinking today about a complexity that I hadn't considered 
before, though.  What happens if a function has out or inout parameters? 
 If we're trying to create something where the function can do use 
(copies of) the local variables after the function has returned, then 
how do we handle these types of parameters?

For now, I'm using structs, but as you said, it's ugly.

David Medlock wrote:
>  From reading the issues, it appears the problem is delegates are just a 
> way of referencing local variables where the function was called rather 
> than true closures.
> 
> For those interested, true closures allow a function to 'capture' values 
> at the time the function is created(not declared), and the values it 
> takes along with it are called upvalues.
> 
> A nice example of this is Paul Grahams challenge to create an accumulator:
> 
> http://store.yahoo.com/paulgraham/accgen.html
> 
> Which is possible with classes and templates, but it fairly messy.
> 
> Lua properly handles upvalues, its design is quite interesting:
> 
> http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/sblp2005.pdf
> 
> -David
> 
> 
> Sean Kelly wrote:
> 
>> In article <opsou4v7p323k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>>> I forgot to mention. This example was actually my test to see what 
>>> happens  with structs vs classes. What I was trying to answer was:
>>>
>>> 1. does passing a struct delegate to a thread stop the struct from 
>>> being  free'd.
>>> 2. does passing a class delegate to a thread stop the class from 
>>> being  free'd.
>>>
>>> The answer to #1 seems to be no. No surprises really, it's a value 
>>> type  stored on the stack, not a reference.
>>
>>
>>
>> Right.
>>
>>
>>> I wasn't sure I had answered #2, to be sure I added a fullCollect 
>>> (see  code below).
>>>
>>> It appears passing a class delegate, prevents the class from being 
>>> free'd,  which is good, I wondered whether the delegate pointer would 
>>> do that, or  if it had been overlooked.
>>
>>
>>
>> Right.  Any GCed object won't be cleaned up until all references to it 
>> are gone.
>> The thread these references are held in is not an issue.
>>
>>
>> Sean
>>
>>
April 08, 2005
Re: new thread with nested function
On Thu, 7 Apr 2005 23:14:17 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> In article <opsovvsbcn23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>> On Thu, 07 Apr 2005 09:52:28 -0700, Russ Lewis
>> <spamhole-2001-07-16@deming-os.org> wrote:
>>> If you allocated the struct on the stack, then it should not be GC'd
>>> until the delegate goes away.
>>
>> So, you think I have found a bug below?
>
> I would expect your sample code to (probably) output:
>
> 5
> 6
>
> At this point the app may print something and it may just explode, as I  
> expect
> 'a' would have gone out of scope.  Best case would be for it to print 6  
> twice
> more and either 5, 0, or something random for the other two lines.  But  
> none of
> this is guaranteed, since nothing says the new threads will actually  
> start in
> the 1 second before fire() exits.

You are correct :)

Regan
April 08, 2005
Re: new thread with nested function
On Thu, 07 Apr 2005 16:03:28 -0700, Russ Lewis  
<spamhole-2001-07-16@deming-os.org> wrote:
> EEK!  Sorry, I mistyped.  What I meant to say was that you allocate it  
> on the *HEAP*, then it should not be GC'd until the delegate goes away.  
>   Structs on the stack definitely *do* become invalid the moment that  
> you return from the function.

Yep. That's what I thought.

Regan
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home