From: Matt Pulver (mpulver_at_[hidden])
Date: 2023-09-06 14:54:32
On Tue, Sep 5, 2023 at 12:43 PM Ruben Perez via Boost <boost_at_[hidden]>
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