Re: Project idea: strbuf allocation modes

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

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.

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