[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pika-dev] Re: plans
From: |
Andreas Rottmann |
Subject: |
[Pika-dev] Re: plans |
Date: |
Tue, 09 Mar 2004 19:30:47 +0100 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
Tom Lord <address@hidden> writes:
> 1) basic data structures not having to do with EVAL
>
> 2) everything having to do with EVAL
>
>
> I would like to focus the project on (1), for now. Jivera has been
> experimenting with things for (2) and I encourage that to continue --
> but let's finish up the stuff in (1) before we "officially" move on to
> that.
>
> The tasks in (1) are:
>
> ~ the missing list and and vector primitives
>
> Andreas is working for sure on some of these, possibly on others.
> I'm sure any of us can take up any slack in this area. This
> stuff is pretty straightforward and presents no new issues -- just
> a handful of functions to write.
>
I've now implemented the missing list primitives, you may pick them up
from my --integration branch at your convinience. I guess the few
vector-related funcs don't warrant a opening a branch for them, if I
were to implement them. So would just committing them to --integration
be OK?
> ~ strings
>
> We're in very good shape now for rounding out hackerlab's t_udstr
> type to provide the basic functionality that we need.
>
> Basically, t_udstr just has to be wrapped (vtable-style) to make
> Scheme strings but there is a catch:
>
> Strings present some interesting challenges for thread-safety and
> async-code safety. I've written a design for how to handle those
> issues (the "object-locks" file in ./src/scm/=PLAN).
>
So, we'd first implement object locks I guess. Most of the stuff would
live in reps/, I think, except for the conviniency function. I could
go ahead and put this in place (fairly trivial, as they're supposed to
be noops ATM). This would result in:
* reps/object-locks-imp.[hc]:
scm_lock_for_object, scm_unref_object_lock,
scm_ref_object_lock
scm_acquire_object_locks, scm_release_object_locks
* libscm/object-locks.[hc]:
scm_lock_objects, scm_unlock_objects
Does that look OK?
Furthermore, to meet your suggestion about having invariants in place,
I think it would be a good idea to already implement reference
counting and the boolean locked? flag, even if we don't have asyncs
ATM.
Regards, 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
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald E. Knuth
- [Pika-dev] plans, Tom Lord, 2004/03/07
- [Pika-dev] Re: plans,
Andreas Rottmann <=