pika-dev
[Top][All Lists]
Advanced

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

[Pika-dev] Re: hashq values and weak references


From: Andreas Rottmann
Subject: [Pika-dev] Re: hashq values and weak references
Date: Sat, 08 May 2004 21:34:29 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Tom Lord <address@hidden> writes:

>     > From: Andreas Rottmann <address@hidden>
>
>     > Andreas Rottmann <address@hidden> writes:
>
>     > > Since you seem quite opposed to the memchunk idea, I took
>     > > another look at the object data areas, and it seems instead
>     > > of having the data in a separate memchunk, we might as well
>     > > keep it in the hashtree items, thus avoiding the memchunk
>     > > issue.
>
>     > At the additional cost that the memory in object data area
>     > must be copied, but I guess that's neglectable unless you
>     > stick large stuff in there (would we?).
>
> I'm a little confused as to what you're talking about.
>
> I'm assuming that you're working solving the hashq problem: that with
> our copying collector an address-based HASHQ is no good -- the address
> of an object can change over time.
>
Yep, while attemting to implement object locks, I discovered a
generalization of a problem inherent to both "hashq problem" and
object lock: associate a data area with a scheme object. I thus
implemented an interface to do so, see [0].

I then implemented the solution to the hashq problem by using object
data areas. My integration branch should have a solution to the hashq
problem already, even if it's not the way you thought it should be
solved (you never commented on my mail[0]...)

I'll comment on the divergance of your proposed approach with the
current state in another mail.

[0] http://article.gmane.org/gmane.lisp.scheme.pika.devel/221

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

It's *GNU*/Linux dammit!




reply via email to

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