Hey Everyone! As you might already know, I recently left my job at Aker to pursue full-time streaming. The video above covers all the important details.
I'd like to give you guys a little sneak peek at the first commercial software project I'm working on: nwr_mem.h
nwr_mem.h is an stb-style mit/public domain single header C library that will provide custom (user-space) memory allocator building blocks inspired by Andrei Alexandrescu's std.experimental.allocator work in the D programming language. The library will include things such as:
Additionally, the library is being written as a literate program, and a pdf file describing the design and implementation of the library will be available.
I want people to use and share my software regardless of whether they back me on patreon, which is why nwr_mem.h will be MIT/public domain, but officially I will only be distributing my copies to $5+ patrons. Think of the distribution model as piracy-made-legal!
The first version of nwr_mem.h that I will be releasing will include the first allocator: Region. The api can be seen below:
It is purely user-space, you can allocate the memory from whatever system allocator you like. When you call something like nwr_region_create you pass it a pointer and length of the memory it is to use as the backing store.
The api is still subject to change, but you can see the create function for the region allocator here:
nwr_region is a struct that keeps track of the region with 3 pointers, an int holding the alignment, and an int holding flags. The region is able to either grow up or down in memory (this is currently all the flags are for). Growing down is useful if you want the region to use memory on the stack for example. One downside of growing down is that you can't expand an allocation in-place though, so nwr_region_expand is only supported for regions that grow up.
What about multi-threaded allocators? Whan you want generic purpose malloc replacement than can be allocated and freed on arbitrary threads without explicitly taking mutex over whole alloc/free function. Any plans for such use case?
I am interested in providing thread-safe/multi-threading aware variants of my allocators but I don't have any specific plans for this on the current road-map, we should discuss this further once I've got a dedicated topic for the library ready :)