>>>>> "BR" == Bob Rogers <[EMAIL PROTECTED]> writes:
BR> Uri Guttman wrote: >> here is an odd thought to add to that. since your hash is a single hunk >> of ram, you could use offsets inside it instead of pointers. that means >> it could be both shareable (given locks) and even writable to disk. BR> I don't see the difference WRT shareable, BR> It sounds like Uri meant that it could be mapped at different addresses BR> for different processes . . . but maybe not, because then the key and BR> value pointers would be useless. i did sorta cover that a little but here are some more ideas. you can make more of the data structure offset based but use an indirection table attached to the main chunk. so a key bucket in the main chunk has an offset into this table (which is not shared) and that entry points to the real key/PMC (which could be allocated from similar chunked memory). i know this is getting deeper and deeper away from basic pointer code but it is something to be explored. if the wins (FSDO win) for sharing and freeze/thaw are worth it, then the extra code and slight slowdowns would be worth it. and as i mentioned in the other response, this could be an optional hash (or whatever) implementation (since multiple implementation are easy in parrot/perl) that uses offsets as much as possible for those wins. so in perl you might declare it like this (p6l folks, please fix this): my OffsetHash %foo ; and class OffsetHash offers 'does Hash' as a role (is that needed?). BR> This may be too obvious to be worth pointing out, but if hash internals BR> are made persistent, then the hash code computation needs to be BR> invariant from one interpreter instantiation to another. For this BR> reason, the "seed" member of struct _hash is probably counterproductive. BR> Not to mention the fact that initializing it randomly would make it BR> harder to test hash iteration, since the key enumeration order would BR> then be nondeterministic. it is a good point to remember and it would have to be that way in the OffsetHash implementation. i like this way of splitting it so the pointer based hash is the common default but if you want better sharing/freeze/thaw, you just have to (auto)load OffetHash and change your declarations a but. there would also be similar classes for arrays and scalars and even a way to force/request allocation of them all from a single ram chunk (we just reinvented PL/I's area :). uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
