Re: Presenting BoostServerTech chat

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2023-09-07 11:42:16

>
> I agree. This is also my case.
>
> While I can understand Ruben focuses on using async libs "all the way",
> unfortunately I don't have that luxury (or honestly the knowledge). In fact,
> some of the "protocols" / APIs I must support allow requesting large amount
> of data, thus I don't want a single request from one client to block all
> other clients.

As I mentioned in a previous email (seems like mailman hasn't generated a URL
I can link to), my approach would be to offload the individual pieces
of sync or heavy work to a thread_pool. The main event loop would still
be single-threaded, dispatching those pieces to the thread pool.

I've added code demonstrating this approach to
https://github.com/anarthal/servertech-chat/issues/44.

> When everything is async, including talking to remote RDBMS's, maybe that
> one big request gets "suspended", allowing other (independent) requests to
> make progress, but in my case with a non-async DB layer to talk to, I don't
> think a single-threaded server is a viable solution.

Would you mind sharing protocols or RDBMs without a sync-only interface are
you interested in? These could make good C++ libraries in the future. I envision
a future where almost every system has an async interface, as it happens in
Python or Node.

Until that future comes, the thread_pool solution seems the best.

Thanks,
Ruben.