Boost logo

Boost :

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: TONGARI J (tongari95_at_[hidden])
Date: 2015-08-25 10:07:22


2015-08-25 21:22 GMT+08:00 Niall Douglas <s_sourceforge_at_[hidden]>:
>
> 2. The reason why it's shared_ptr<handle> not handle * is precisely
> because of how to manage lifetime over unknown continuations. If the
> user writes:
>
> future<> oh=async_file("niall.txt");
> future<> reads[100];
> for(size_t n=0; n<100; n++)
> reads[n]=async_read(oh, buffers[n], 10, n*4096);
>
> So this schedules niall.txt to be opened, and then adds 100
> continuations onto that file open each of which schedules the read of
> 10 bytes from a 4Kb multiple. All those 100 continuations occur in
> *parallel*, and could complete in *any* order.
>
> So how do you keep the handle to the niall.txt file around until the
> last continuation using that file has completed which is at some,
> unknown point in the future? The natural fit is shared_ptr. It's
> exactly what it was designed for.
>
> Does this make sense?

I think it's an design issue, I wonder if it's possible to design the API
around the ASIO model, e.g.

```
afio::file file(io); // move-only
await file.async_open("niall.txt");
future<size_t> reads[100];
for(size_t n=0; n<100; n++)
  reads[n] = file.async_read(buffers[n], 10, n*4096);
```

Drop the dependency based API, since the forthcoming coroutine should solve
it for you elegantly.
This way, you don't need shared semantic for future<>, just like how we
used to do with ASIO.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk