Implementation of IO with Panama

[Maurizio Cimadamore]

On 19/04/2021 11:41, Radosław Smogura wrote:
> Frankly, I came out with idea of child allocator, when I realized that during some operations you need to allocate one or two struct or CStrings, and it would be just handy to manage it via try-with-resources.

Yes - but I think it was a "happy realization". If you create a new 
resource scope for each new returned segment, things might be ok for 
confined case, but would probably be not very efficient in the case of 
an allocator backed by a shared scope - where you will pay for an 
expensive synchronization each time a new shared segment is returned to 
the pool.

Since your API works at a different level of granularity (scopes, not 
single segments), it largely avoids these issues (as one would assume 
that clients would create a scope for something "more" than to create a 
single segment).

>   
>
>> Then, on each allocator request you use `getSegmentForScope` which internally register a callback (on the client scope) for `putSegmentEntry`, which returns the segment to the pool. It seems all very consistent. With this design, the client can use confined, or shared segments, and you get same performances, as clients are not expected to call "close" on each segment - but you work on a scope granularity instead (which the API encourages).
>>
>> So, if a client use the SegmentAllocator API, everything should be safe right? But you also expose a lower level API to, presumably, avoid the segment allocator. How much is it gained by that?
> The difference in performance when using low level API versus allocator is around (5.6M vs 5.7M req / sec). However this test was for allocating single segment

Ok it seems like the performance loss is not dramatic, but you gain 
safety back.

Thanks for the comments
Maurizio