TL;DR I think that a good start for such a library would be to carve out Ensemble’s “iovec” library. But most people would see that as going too far, I fear.
it is difficult to implement such a thing for -any- language, because all the hard parts involve the interaction with the “host system”. That is, how will the pool library recognize that a particular buffer is no longer in use, and can be recycled? It’s everything, really. If we make the assumption that there’s a definite entrypoint (e…g “release()”) that signals that, then sure, it’s easy to create such a generic library. And so, for Java/J2EE, where much of the pooling happens in layers of “I/O streams/readers/writers”, that’s possible, b/c those have well-defined lifetimes (associated with the request/response lifecycle. In this case (of capnproto) that’ll be true also, for similar reasons, except that it will require caveats to users that they must not retain pointers to incoming messages, etc.
Also, if you’re really concerned about this sort of performance, you don’t want those buffers to be in the major heap, either, yes? You’d want them outside the heap completely. Going further, if you’re -really- concerned about performance, e.g. let’s say you’re working with an Infiniband/RoCEE card, you’re going to want to pin those buffers to physical memory and register them with the card and associated kernel library. More complexity.
I did the above with Ensemble’s “iovec” library, and it was quite lovely. Thing is, it’s 'way overkill for most applications, that just don’t need microsecond-level performance.