[foreign] from memory segments to byte buffers

[Maurizio Cimadamore]

On 22/03/2021 14:05, Pedro Lamarão wrote:
> Em seg., 22 de mar. de 2021 às 10:26, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> escreveu:
>
>     > Now that we have got a taste of being able to de-allocate a BB
>     deterministically *AND* at the same time being able to pass it
>     around whatever we want like before, it will be hard to go back to
>     the world you are proposing, the actual semantics is very
>     convenient because it doesn't require to change the existing codes.
>     I don't think the "it doesn't require changes to the existing
>     code" is
>     really true though: if you have a byte buffer backed by a memory
>     segment
>     that is closeable, then your code is not sound unless you use the
>     ResourceScope.acquire method when you set up the byte buffer.
>
>     So my email was more about "should the API do the acquire
>     automatically" ?
>
>
>
> Have you considered the interaction with asynchronous I/O?

Yes - that is why the new API has ResourceScope::acquire. That is, we 
are able to make a scope (from which a segment is derived) non-closeable 
for a certain span (e.g. when a buffer is enqueued for an async op).

Maurizio

> The buffer life must match the operations life, which is not bound to 
> any local scope.
> Of course, in a native API, the user would be required to assure the 
> buffer has an appropriate life time.
> So this particular case may reduce to a usability decision on 
> asynchronous I/O,
> which may be considered advanced enough so that such requirements are 
> reasonable.
>
> -- 
> Pedro Lamarão
> https://www.prodist.com.br 
> <https://urldefense.com/v3/__https://www.prodist.com.br__;!!GqivPVa7Brio!NiXvstU26vx35ShoBrDiOvUNgq1jM9isWY0JpU1P1BD6eZ-SHKpy7hZDtRoxazKnNVKb2mU$>
> Securing Critical Systems
> Tel: +55 11 4380-6585
>
> Antes de imprimir esta mensagem e seus anexos, certifique-se que seja 
> realmente necessário.
> Proteger o meio ambiente é nosso dever.
> Before printing this e-mail or attachments, be sure it is necessary.
> It is in our hands to protect the environment.
>