help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] .st file naming


From: Jan Vrany
Subject: Re: [Help-smalltalk] .st file naming
Date: Thu, 16 Apr 2015 07:45:21 +0100

Hi, 

sorry, I overlooked this post...

> > On 09 Apr 2015, at 02:33, Jan Vrany <address@hidden> wrote:
> > 
> > Hi, 
> >> OK, let's do some experiments first to get some data. 
> > 
> > I did some quick changes to keep track of packages as
> > I suggested: 
> > 
> > https://github.com/janvrany/gst/commit/0123cc6d00fdf0cf0781b308ebbe4ba96e70292e
> > 
> > This is certainly not complete: no package tracking in classes (i.e.,
> > ClassInfo), no API yet, no overwrites support, no support in browser, 
> > no extensive testing, …
> 
> neat! How confident are you that Current and _gst_current_package will
> stay in sync? 
> 

I have same level of confidence as for Namespace and _gst_current_namespace. 
I just followed the same pattern. 
Not that I particularly like this pattern - It would be lot better to
have an API to access class vars from the C. Then we won't have this problem
at all (and won't depend that much on a particular implementation of 
a memory manager :-)

> 
> With the failing primitive we mostly avoid having to deal with
> protecting the package in C
> 

Right. 

>  but this assumes that from failing to assignment
>  nothing else will be executed. :)
> 

I think the code is correct. It reads:

1209   Package class >> current: aPackage [
1210        <category: 'accessing'>
1211        <primitive: VMpr_Package_setCurrent>
1212        Current := aPackage
1214   ]

Even if a lot of GC happens in between the assignment
in a primitive and in the method above, the package
object cannot be GC'd because it's held by the method's
context. When the context is gone, it's already assigned
in the class var, so it cannot be GC'd.

Jan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]