[Top][All Lists]
[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!
- [Pika-dev] hackerlab fsplay.[ch] status, Andreas Rottmann, 2004/05/02
- Re: [Pika-dev] hackerlab fsplay.[ch] status, Tom Lord, 2004/05/02
- Re: [Pika-dev] hackerlab fsplay.[ch] status, Tom Lord, 2004/05/06
- Re: [Pika-dev] hackerlab fsplay.[ch] status, Andreas Rottmann, 2004/05/06
- Re: [Pika-dev] hackerlab fsplay.[ch] status, Tom Lord, 2004/05/07
- Re: [Pika-dev] hackerlab fsplay.[ch] status, Andreas Rottmann, 2004/05/07
- [Pika-dev] Re: hackerlab fsplay.[ch] status, Andreas Rottmann, 2004/05/07
- [Pika-dev] hashq values and weak references (was hackerlab fsplay.[ch] status), Tom Lord, 2004/05/08
- [Pika-dev] Re: hashq values and weak references,
Andreas Rottmann <=
- [Pika-dev] Re: hashq values and weak references, Tom Lord, 2004/05/10
- [Pika-dev] Re: hashq values and weak references, Andreas Rottmann, 2004/05/10
Re: [Pika-dev] hackerlab fsplay.[ch] status, Tom Lord, 2004/05/06