Re: Project idea: strbuf allocation modes

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Apr 22, 2014, 10:38 UTC
Message-ID: <vpqa9bdsl7p.fsf@anie.imag.fr>
In-Reply-To: <535631C0.2020100@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

> On 04/22/2014 09:07 AM, Matthieu Moy wrote:
>
> The whole point of the change is to *allow* strbuf to be used in
> performance-critical stuff.

OK. It should not make the current use of strbuf any harder anyway.

Show 7 quoted lines

>> In your proposal, would STRBUF_OWNS_MEMORY be a constant, or a flag that
>> change when the internal buffer needs reallocation? My understanding is
>> that it should change (if STRBUF_FIXED_MEMORY is not set), and the
>> strbuf wrapping a preallocated buffer would become a "normal" strbuf
>> when its internal buffer grows.
>
> Correct.  STRBUF_OWNS_MEMORY itself is of course a constant like 0x02

Yes, I meant "the STRBUF_OWNS_MEMORY flag".

> How does the size of this project compare to what you are looking for
> for your Ensimag students?

I do not yet have applications for this project (it should come within the next few days). It greatly depends on students and team size. I always start with a "warm up patch" (like GSoC's microprojects), and depending on the time taken for it, I direct students to bigger or smaller projects.

Your proposal is a bit tricky (it requires a good understanding of C and memory management), but it is a purely local change (i.e. you can take strbuf.[cf] out of Git's source code and hack it as a ~500 LOC project, unit-test and document the result in a self-contained way), so it should be doable. Using the new API features here and there in Git's source code is another story though.

I've added the proposal with a link to this discussion here:

  https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Allow_finer_memory_management_in_the_strbuf_API

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/