> -1 (veto) to both suggestions.
>
> This is getting obscene.  We've lost all value of tables, since they can't be 
>memcpy'ed,
> they have to be reconstructed.  This will be much slower than the original array 
>code.
>
> Committers, please review dir_create() and dir_merge() patches more carefully.  There
> is a long tradition of configuration bugs due to these assumptions.  The patches that
> added copy/copy_mappings was an attempt to salvage this.
>
> I'll demonstrate a solution, using pool scopes, that adds safety and speed.  Give me 
>a
day.
>

Hit send before I was finished.  If pool scopes significantly increases the complexity 
of
this code, I will likely veto it.  So you might want to share what you are planning on
doing before you invest much time in it.  I learned a lesson working on this code... 
the
dir_create() and dir_merge() code needs to be as straight forward and easy to 
understand
as possible to keep bugs out.  Gaining 5% performance at the expense of a 100% 
increase in
code complexity is not an acceptable trade off. The copy_mappings, et. al. was more 
like a
1000% increase in complexity.

Bill

Reply via email to