[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pika-dev] Re: vtable bug (Re: Replacing cport [...])
From: |
Andreas Rottmann |
Subject: |
[Pika-dev] Re: vtable bug (Re: Replacing cport [...]) |
Date: |
Wed, 17 Mar 2004 23:21:38 +0100 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
Tom Lord <address@hidden> writes:
> > From: Andreas Rottmann <address@hidden>
>
> > > Unfortunately, it also has:
> > >
> > > void * scm_binary_data_addr (t_scm_arena arena, t_scm_word *
> value);
> > >
> > > That one is problematic. Unless VALUE is locked, the address returned
> > > can not be trusted. A copying collector can move it at any time.
> > > (This would be a good example of how even "noop" locking code can be
> > > handy --- scm_binary_data_addr could verify that VALUE is, indeed,
> > > locked.)
> > >
> > So should I add a scm_object_lock_is_held() or so function? The same
> > issue also comes up with scm_string_value(), which turned to public
> > function with my latest string foo (not yet published).
>
>
> I was going to say: scm_object_lock_is_held should not be in any
> public API, at any level. Maybe some need for it will show up down
> the road.
>
> No, I just meant an `invariant()' inside of `scm_binary_data_addr'.
>
> But, hmm.... I suppose that lock_is_held could be in a public API for
> just exactly that reason --- to enable people to write invariants.
>
Yep, that was the intention.
> Maybe, to discourage abuse of it, make it a macro named:
>
> scm_object_is_locked_invarient
>
> with the spec that it panics should it's argument not be locked
> (rather than making it a predicate).
>
That's a good idea, IMHO.
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
Any technology not indistinguishable from magic is insufficiently advanced.
-- Terry Pratchett