RE: Caching question

Ok, so basically you're saying "Don't do that" :)


"Promotion of Moto Defined Classes is clumsy. The class itself AND all
of its member variables must be promoted."

heh, yeah this took me a few iterations to get everything promoted.
Didn't realize I had to promote a String contained in an object.



Shay


> -----Original Message-----
> From: David Hakim [mailto:dhakim-Gkm/TONP9n1Wk0Htik3J/[email protected]] 
> Sent: Wednesday, February 12, 2003 8:46 AM
> To: Shay Harding
> Cc: Moto Devel
> Subject: Re: [moto-devel] Caching question
> 
> 
> 	There are a couple of things that may be causing this behavior.
> 
> 1) The most common reason this happens is that the module was 
> compiled 
> against a different version of moto (or moto extensions) than the 
> interpreter is loading. Under linux all symbols live in one namespace 
> so objects allocated by the interpreter are seen by the compiler and 
> vise versa. Moreover the dynamic loader under linux will 
> always look to 
> see if a symbol has already been loaded and if so use that 
> symbol. Thus 
> if a function or method defined in an extension changes, if 
> there is an 
> older mmc compiled module already loaded (that was compiled with the 
> old version of an extension function with the same name), the old 
> version will be used. I want to address at least some of the symbol 
> versioning problems in future versions of moto by allowing a 
> flag to be 
> passed to mmc to make the mmc compiled module dependent on the shared 
> version of an extension as opposed to the static version.
> 
> 2) Moto Defined Classes can at times have different runtime 
> representations in compiled vs interpreted code. While this usually 
> isn't the case ... sometimes it is. I'm hoping to unify their 
> representations during the implementation of inheritance. The real 
> problem with these different representations is that on linux, when 
> both interpreted code and compiled code are running on the same 
> webserver they share the same shared segment. So when you put 
> an object 
> into the context from interpreted code, it may be taken out 
> and used in 
> compiled code (and vise versa). Unfortunately if the object has a 
> different representation in interpreted and compiled modes 
> methods from 
> one may not work right on objects allocated by the other.
> 
> 3) Promotion of Moto Defined Classes is clumsy. The class itself AND 
> all of its member variables must be promoted. I'm hoping to 
> get rid of 
> the idea of promotion all together one of these days with the 
> inclusion 
> of a real garbage collector. I've had one mostly built for a 
> while but 
> its performance leaves too much to be desired for inclusion at this 
> point.
> 
> -Dave
> 
> On Wednesday, February 12, 2003, at 08:36  AM, Shay Harding wrote:
> 
> > Is there a conflict between compiled moto mods and interpreted in 
> > regards to caching objects then retrieving them?
> >
> > I have a small moto program that stores data in a SymbolTable then 
> > promotes everything and caches it so the data is persistent. 
> > Everything works fine if I only run it from interpreted OR 
> only run it 
> > from compiled. When I run the interpreted then run the 
> compiled (or in 
> > reverse order) I get errors about null objects and such. The 
> > interpreted version actually doesn't kick out an error, it 
> just causes 
> > the Apache child to segfault.
> >
> >
> >
> > Shay
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
> >
> >
> >
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003