On Tue, Sep 5, 2023 at 12:43 PM Ruben Perez via Boost <boost@lists.boost.org> wrote:
I'm Ruben, the author of Boost.MySQL, and I want to present (and maybe get some feedback about) a project I'm developing to showcase how to do async stuff with Boost server-side.
... So I've decided to [...] create a project that
allows Boost authors to try new things in a realistic environment, while demonstrating to users how they can use Boost to build an app.
Very nice. From https://github.com/anarthal/servertech-chat/#architecture in describing the example app: The server is based on Boost.Beast, asynchronous (it uses stackful
coroutines) and single-threaded.
This is a good/appropriate introduction for programmers to experience developing what has the power of an asynchronous application but with the simplicity of a single-threaded application without the need for locks. A more advanced app, and what I would like to see personally, is an example and architectural discussion on design patterns involving how best to handle server requests that require more time/resources that may not be appropriate for a single-threaded server (e.g. a database server.) From a high-level perspective, my current thinking on this is: - Handle fast requests in the main single-threaded boost.asio event loop (assuming they don't access resources locked by the next bullet point.) - Handle longer requests by delegating to a separate thread pool that triggers a callback when done, without blocking the single-threaded event loop. The threads in the separate thread pool do "traditional locking" via mutexes, read/write locks, etc. Are there more modern approaches/techniques? In either case, a discussion about these issues would be valuable IMHO after the introductory example. Thank you, Matt