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

[Dirk Herrmann]

Marius Vollmer wrote:

>  Rob Browning <address@hidden> writes:
>
> > 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.
>
>
>  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.

I can not understand at all, why we should introduce such a concept from 
the start: The non-locking related API allows users to do all they could 
want to do. Locking is only introduced to avoid performance problems due 
to memory allocation when extracting string contents. This early 
optimization is done at the wrong time. Before we don't even have an 
implementation without locking available, we don't know how much of a 
problem the memory allocation really is for a typical application. If it 
later appears that the real performance problem comes from the fact that 
our internal memory organization of strings is bad, we are stuck. If it 
later appears that the global locking introduces more performance 
problems than it solves, we are stuck.

Further, to really be able to rate the design of the global heap 
locking, I need more information about how it would be implemented: What 
exactly would happen at the moment one thread calls scm_lock_heap? What 
is the performance penalty for additional thread-switches due to the 
global locking? How much is it compared to the expected performance gain 
for the typical application? Which parts of guile are affected by 
introducing the global locking concept?

In general, I think the proposal is a step in the right direction. My 
suggestion is to start with the non-controversial stuff and provide 
users with an API that allows them to do everything they want, and 
postpone the performance optimization issues. As far as I see it, the 
global locking could be added later without influence on the rest of the 
API.

Best regards
Dirk Herrmann