[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pika-dev] Re: plans
From: |
Tom Lord |
Subject: |
[Pika-dev] Re: plans |
Date: |
Tue, 9 Mar 2004 11:17:05 -0800 (PST) |
> From: Andreas Rottmann <address@hidden>
> > 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.
Thanks.
> 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?
That'd be fine. Thanks.
> > ~ 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?
Yuppers.
> 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.
Yes, that'd be great.
-t