Re: [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-08-31 15:17:55

On 08/31/2015 06:53 PM, Niall Douglas wrote:
> On 31 Aug 2015 at 16:50, Thomas Heller wrote:
>
>>>>> 7. future.wait() very rarely blocks in your use scenario i.e. most if
>>>>> not nearly all the time the future is ready. If you are blocking, the
>>>>> cost of any thread sleep will always dwarf the cost of any future.
>>>>
>>>> Is this really an assumption that holds when dealing with operations
>>>> that do file I/O? I have a hard time believing this is the general case.
>>>
>>> Imagine the copying of a 10Mb file in 1Mb segments. You would create
>>> a minimum of 11 future-promise pairs, and only wait on the very last
>>> one.
>>>
>>> My own benchmarking here suggested that (much) lighter weight futures
>>> would let me implement a much more efficient ASIO reactor than ASIO's
>>> and push all potential blocking to outside AFIO, perhaps right down
>>> to the final end user layer. Perhaps thousands of future-promise
>>> pairs might be created, continued from and destroyed between actual
>>> thread blocks. This is why I believe - currently without real world
>>> proof - this ought to be a big win.
>>
>> How does this answer my question?
>
> Well, you asked:
>
>>>> Is this really an assumption that holds when dealing with
> operations
>>>> that do file I/O? I have a hard time believing this is the
> general case.
>
> I assumed you didn't want me to simply say "accept it's true", so I
> tried to explain how even a simple operation outside AFIO may turn
> into multiple promise future constructions and additions of
> continuations.
>
> None of those get wait() called on them, and therefore you very
> rarely block. As an example, if you executed 1000 promise + future +
> continuations but blocked on just one of those, my condition
> "future.wait() very rarely blocks in your use scenario" is fulfilled
> by virtue that future.wait() is simply never called.

Looks like a problem with my english, sorry, I am not a native speaker. 
Let's see if I got it correct now: "Your code rarely calls 
future<T>::wait to avoid blocking because that is usually costly".

 From my experience that holds true for any future implementation (be it 
based on OS synchronization primitives or user level context based 
synchronization), and is probably the number one reason why one would 
want something like future<T>::then, when_all and friends.

So I take it that this requirement is nothing special to your 
lightweight futures.

>
> Niall
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>