pika-dev
[Top][All Lists]
Advanced

[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




reply via email to

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