Re: [boost] Asynchronous library now in Boost Library Incubator

Subject: Re: [boost] Asynchronous library now in Boost Library Incubator
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2016-12-06 17:44:33

>> From what I understand, I don't think both examples are equivalent (yet):
>> - the lifetime issues are not visible in this example. There is a single
>> object and it is living in main's thread, which removes quite some salt. It
>> has no interaction whatsoever with other threads or objects. My example
>> shows interaction with the main thread.
>>
>>
>> This does too.

Then replace "main thread" by "another thread than the one which created 
the object".

> It would be great if we'd speak the same language as well, why not call
> your thread worlds executors and open a whole new world of possibilities ;)

:)
Because they're not. Please have a look at the definitions.
I think your executors would be more a scheduler or a scheduler shared 
proxy (which shuts down a scheduler when no more needed).
A thread world is the scheduler, hem sorry executor, and the objects 
living inside.
A thread world enforces compartmentalizing objects into 
schedulers/executors.

> Don't get me wrong, I'm not really trying to say that libraries like hpx,
> or boost.thread or folly or ppl solved your problem. I was trying to
> demonstrate that futures, async and friends are not your enemies, on the
> contrary.

I think they are your friends ;-)
Mine are callbacks. Blocking futures are my enemies. I'm still unsure 
whether there is such a thing as a non-blocking future.

> Regarding the layered example, I'm still trying to understand the semantics
> of your different APIs. There are a lot of things doing the same from a
> different perspective (proxy, servant, scheduler).

Sorry about that. One of the reasons for starting discussing the library 
before the review is that my team and I are using the library since so 
long that we're not seeing any more what others do not understand. Thank 
you for your help pointing me the difficulties.
I clearly have to make this clearer in the doc.

A scheduler = I suppose, roughly your executor.

The next two: see Active Object Pattern Gang of Four.
The names are chosen as to correspond to the pattern.

A servant = an thread-unsafe object like the manager of our example, 
living into a single-thread-scheduler.
A servant proxy = A thread-safe object behaving like the servant it 
represents, for usage by outside threads.