tursodatabase
Feature: per-connection memory allocator configuration
I have a use case where I want to specify a custom allocator per connection. (The general form of the use case is to specify an arena allocator for an object that opens its own connection. This occurs in a process that is long lived [an application in my case] and that may spawn multiple concurrent instances/connections.)
In SQLite you can configure a custom allocator at the process level, but not per connection.
That AI-generated solution looks like the kind of path to take! Of course, we should also switch to allocator-api2 which gives Zig-style explicit allocators.
I'm a mega fan of this feature. I would love to implement it myself but if someone comes with something nice then I'm all for it.
allocator-api2 is the way! I tried to use bump allocator (bumpalo) and that was a fool's errand due to lifetime annotations polluting many structs.
@penberg is it possible to statically allocate all the memory needed at the startup similar to TigerBeetle in the case of limbo?
I'm not yet that well versed in the workings of SQLite memory allocator but it seems like it tries to do static memory allocation where ever possible using lookaside memory allocator, more about this here
allocator-api2 is the way! I tried to use bump allocator (bumpalo) and that was a fool's errand due to lifetime annotations polluting many structs.
I've never done allocators in rust and once I tried bumpalo. It is 100% true that lifetimes get in the way and I hate it so much with passion.
@penberg is it possible to statically allocate all the memory needed at the startup similar to TigerBeetle in the case of limbo?
I believe this is hard in our case as there could be multiple big blobs being pushed or things like that. Maybe possible but it requires a lot of thinking of a bunch of edge cases. I believe good choice of allocators per stage + giving control to the user is the goal.
The question on static allocation is interesting! I tend to think TigerBeetle's approach here is too extreme for my taste and that throwing away dynamic allocation makes the code too complex. Of course, perhaps I should not be saying anything here about complexity as I threw away Rust async without blinking... Also, having SQL as the interface to this library means that it can be really hard to figure out how much memory you need because queries can end up being pretty complicated (just think about joins, group by, etc.) whereas I believe TigerBeetle's domain specific interface is much simpler and, therefore, makes the approach more sense.