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

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> Having a lock for every object would have a high overhead and give
> you very little in terms of performance, I guess.  Also, they would
> be tricky to use.

You definitely wouldn't want a lock for every object.  I was mostly
thinking of objects where (for efficiency or whatever) we felt that we
needed to provide the more primitive access (like strings and uniform
arrays).  There wouldn't be an efficiency argument for locking
anything smaller.

> Locking the heap really means putting you into a completely
> different world; none of Guile's functions can be us while the heap
> is locked.

Yep.  That's why I'm concerned, and I'd like to make a rare case where
non-guile-hackers actually need to lock the heap.

> When some function calls scm_unlock_heap, it likely expects the heap
> to be unlocked after that call and starts to use normal libguile
> functions again (doing allocation, for example).  When the heap has
> not in fact been unlocked, well...

That makes sense.  I've been sensitized to the threading case where if
you don't have recursive locks, you can end up needing a lot of
foo_lock and foo_nolock versions of functions or needing a "grab_lock"
argument, if you want to be able to use those functions as building
blocks for higher level functions.  Of course recursive locks have
their own issues.

> Yes, that would be a good addition.  However, I'd still want to have
> the low-level functions (scm_lock_heap, scm_l_* etc.) available.  You
> can use them to code the more convenient variants, but it is unlikely
> that we can provide convenience variants for all cases.
>
> For example, you might want to pass a string to gdk_draw_text, or to
> libc fputs, or to some other function that works with raw strings that
> you know is OK to be called with a locked heap.
>
> This would be a typical use
>
>   int
>   write_scm_string (int fd, SCM str)

I can see the argument, but I'm also concerned that we're adding
another function category that people have to keep track of,
"functions that are safe to call with a locked heap".  With scm_l_foo
it's fairly clear, but what about other functions?  Will some
non-guile functions be safe and others not, or will all non-guile
functions be safe?

However, if we can provide the "copy into buffer" varieties for the
common cases, and also provide common things like write_scm_string
ourselves, then we should be able to make the need for locking so low
that it wouldn't bother me, and we can document it with all kinds of
warnings.

-- 
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