pika-dev
[Top][All Lists]
Advanced

[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




reply via email to

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