stlab documentation, best practice and performance about libraries HOT 3 CLOSED

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.

from libraries.

@chenziliang

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

from libraries.

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.

from libraries.