Re: [PATCH] btree: Add custom allocator interface.

[Rusty Russell <rusty@rustcorp.com.au>]

Stuart Longland <stuartl@longlandclan.id.au> writes:
> On 08/02/16 10:45, Rusty Russell wrote:
>> stuartl@longlandclan.id.au writes:
>>> From: Stuart Longland <me@vk4msl.id.au>
>>>
>>> This provides a way for btree to be used with external allocator
>>> libraries such as the tal or talloc modules.
>> 
>> Sure.  In my libraries I generally use a global allocator override;
>> it's not thread-safe, but much easier to use in practice.
>> 
>> Since I don't use btree, I'm agnostic about it though!
>
> Indeed, actually I'm half considering whether we make it a separate
> module that `btree` (and others) can pull into their code.  There are
> lots of cases where `tal` or `talloc` is desirable over the standard C
> malloc/free.

Yes, I've been all over the place on this.  Opt has opt_set_alloc(),
(a global), rbuf takes an explicit realloc function, io just assumes
tal, tal/grab_file is actually a tal submodule (the old one is
deprecated, will be removed RSN).

There's a balance of "big enough that needing tal is not an issue",
"standalone enough that I want to avoid a dependency" and "API
simplicity".

>>> +struct btree *btree_new_with_alloc(btree_search_t search,
>>> +		const struct btree_allocator *alloc)
>>> +{
>>> +	struct btree *btree = (*(alloc->malloc))(alloc, sizeof(struct btree));
>> 
>> You can call a function pointer, so alloc->malloc(alloc, sizeof(struct btree));
>> should work.  
>
> Ahh, didn't know about that.  I presume a more recent C standard?  I'll
> admit I had to look up the syntax for function pointers off Wikipedia as
> I don't do it often enough.

It's one of those weirdnesses that has been around forever; pretty sure
it was in K&R but I don't have that on hand.

Cheers,
Rusty.
_______________________________________________
ccan mailing list
ccan@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/ccan