Re: GH replacement proposal (includes a bit of Unicode)

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> Hi,
>
> I have a partial proposal for making type conversions between Scheme
> and C easier.

Overall, I like it, and most of the comments I thought of have already
been covered by Paul, Dirk, and others.

>   These two functions lock and unlock all SCM objects (the heap).  The
>   heap should not be locked for long periods of time and no calls to
>   'normal' libguile functions are allowed while it is locked.  A
>   function is 'normal' unless it is specifically documented to be
>   useable with a locked heap.  (Indeed, most 'unnormal' functions can
>   _only_ be used while the heap is locked.)
>
>   You can not lock the heap twice.  Calling scm_lock_heap while the
>   heap is already locked results in undefined behavior.  Likewise,
>   calling scm_unlock_heap when the heap is not locked is verboten.
>
>   - const unsigned char *scm_l_get_utf8_string_mem (SCM str);

I'm a little wary of the locking, especially global locking, but I
suppose it may well be necessary.  I don't have a strong feeling
either way offhand, but presuming for the moment that it is necessary,
then is there any way to lock down a particular value rather than the
entire heap?  Also, could and should we make it easy to install a
frame unwind handler that unlocks the heap when acquiring the lock?
Finally, what's the argument against allowing recursive locking by the
same thread, too expensive?

On a related note, in many cases, I suspect all the user may really
need is a cheap way to copy some offset + size chunk of the data into
their own buffer, especially when dealing with homogeneous uint8
arrays.  If so, then it might make sense to provide a set of functions
that can do that, handling whatever locking and memcpying is needed.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4