Re: Caching question

On Wednesday, February 12, 2003, at 11:07  AM, Shay Harding wrote:

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

Not exactly ... I'd like to say please keep doing that :) Then find out 
exactly what's going wrong in your case and help me fix it :)

>
> "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.
>
Yeah, it sucks ... the ability to introspect classes that we will get 
out of the inheritance implementation should help a lot with this. We 
should be able to make 'promote' a method of all objects. When called 
the object itself can go through all of its members and promote them.
>
> Shay
>
-Dave

>> -----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
>
>
>