stlab documentation, best practice and performance

[chenziliang]

Hi stlab team,

may i ask have some inquiries regarding this nice library ?

1. Is https://stlab.cc/ the best place i can find the API document ? The document there seems not complete and i was trying to look for more examples for the APIs and i was also looking for best practices to use the APIs.
2. Regarding the major goal of this lib, does it essentially try to provide the capabilities / functions to construct concurrent execution graph via a better future and modeled via CSP ? (Like to confirm this understanding after I watched Sean's Better Code : Concurrency talk and after reading https://stlab.cc/concurrency/2017/05/11/concurrency.html). And is there a milestone for this lib and what it will look like in future ?
3. I glossed over some of the code, look like it supports different type executors : libdispatch, Qt, default (portable) etc. May I ask if there is a perf comparison among them ? The default portable one is very handy for my case, so would like to poll if we have some benchmark numbers around it.
4. It seems the C++ community is also proposing the send / receive / executor service etc papers, i would assume stlab will have some major functionalities overlap with those papers if standardized ? What's the envision using stlab in a event loop system ?

Thanks

[sean-parent]

1. Yes, stlab.cc is where the documentation is posted, which is still incomplete.

2. Yes, futures strive to be a better future model by supporting regularity and cancelation (and similar for channels). We haven't set a milestone for the library. The library was initially created from the example code for the talk you cited and has evolved since then (more in answer to 4).

3. The portable implementation of the default executor is on par with libdispatch and outperforms the other implementations. The reason for having multiple implementations is that an application with more than one thread pool oversubscribes the hardware and may reduce performance. Using their provided thread pools is recommended if you run on Apple platforms, Windows, or within QT. Both the Windows thread pool and libdispatch have kernel access, and so can do a better job at spinning up additional threads as needed without relying on invoke_waiting().

4. At some point, there will likely be a significant update to the stlab concurrency library to augment the sender-receiver model. The standard proposals lack support for a system executor, and I'm convinced the cancellation model in sender/receivers is wrong (or at the very least I don't see how to make it work. What sender/receivers get correct is a lightweight composition model by deferring parallelism. stlab::future continuations were not intended to be lightweight, but I frequently see them used as if they were. What I currently have on my list for a future revision is:

5. Provide a deferred sender/receiver model for futures supporting cancelation on destruction. a. As part of this, I'll likely make future destruction blocking (same as senders) to better support structured concurrency without function coloring.

6. Provide an actor model for serialized access to state. See PR #525.

7. Provide full C++ coroutine support to the channel library to support "Go Routine" style code.

[chenziliang]

Hi @sean-parent, appreciated for your detail response. The bulletin points 4 ~ 7 above look significant and especially 6 and 7 since they are exactly something I wish to have.

BTW, regarding stlab Slack channel, is it private ? It seems requiring an invitation since @meetingcpp email address is required. Would like to join the Slack if i could to follow more discussion etc.

[sean-parent]

@chenziliang

https://join.slack.com/t/stlab/shared_invite/zt-24bezet5e-9PlXy_FWyrvPXpG6znqa7g