Closed sergepetrenko closed 5 months ago
@Gerold103 BTW I noticed there's a separate lsregion_asan
implementation. Do I need to provide lsregion_to_iovec
for it as well?
BTW I noticed there's a separate
lsregion_asan
implementation. Do I need to providelsregion_to_iovec
for it as well?
Yep, it seems like you do - we use different implementations of small allocators for ASAN-enabled builds to detect leaks and invalid accesses.
Cc: @nshy who implemented the feature.
Yep, it seems like you do - we use different implementations of small allocators for ASAN-enabled builds to detect leaks and invalid accesses.
Cc: @nshy who implemented the feature.
Ok, thanks!
I've added the asan implementation and rearranged the test a bit:
lsregion is a good candidate for an output buffer, maybe even better than obuf:
Obuf may be freed / flushed only completely, meaning you need two obufs to be able to simultaneously flush one of them and write to the other.
At the same time, lsregion may be gradually freed up to the last flushed position without blocking the incoming writes.
In order to use lsregion as an output buffer, introduce lsregion_to_iovec method, which will simply enumerate all the allocated slabs and their sizes and save their contents to the provided iovec array.
Since the last flushed slab may still be used by further allocations (which may happen while the flushed data is being written), introduce a lsregion_svp helper struct, which tracks the last flushed position.
Last flushed slab is determined by flush_id - max_id used for allocations in this slab at the moment of flush.
Compared to obuf (which stores data in a set of <= 32 progressively growing iovecs), it's theoretically possible to overflow the IOV_MAX (1024) by using lsregion, and thus require multiple writev calls to flush it, but given that lsregion is usually created with runtime slab arenam, which allocates 4 megabyte slabs to store the data, it's highly unlikely. It would require allocating 4 gigabytes of data per one flush.
Needed for https://github.com/tarantool/tarantool/issues/10161