Allow using wrappers around custom dispatchers

[sakshamsharma]

Gist:
My particular use-case requires using a custom event dispatcher that selects on file descriptors. I spent a lot of time trying to make that happen with boost::asio::io_service, and concluded that it can't be done (correct me if I'm wrong).

So I'm proposing something different. Allow passing a custom wrapper type instead of boost::asio::io_service to the CliLocalTerminalSession and other objects. This can be done via a template argument defaulting to io_service, or it can be done by expecting a virtual interface that can be pre-implemented for io_service in a helper header.

I can pick this up myself as well when I get time, if there are no objections to the direction.

Basically what I would like to do in my custom wrapper interface / type is: I would make a pipe file descriptor dirty before actually calling Post on the io_service. In my main thread, the dispatcher would be calling select on the other end of the pipe (another file descriptor). It would then call poll on the io_service.

[sakshamsharma]

Actually while attempting to fix this, I realized that this won't be a very holistic solution.
https://github.com/sakshamsharma/cli/commits/plugin
Well, it works. But only for local sessions.

Basically, any such approach will be helpless when it comes to network data on boost sockets. It appears that boost does not take kindly to other dispatchers trying to do its job ( :sad: ).

Until then, I have adopted a different approach for this, where I launch one thread with an ios.run(), and I made my CmdHandler lambdas (running in the boost dispatcher thread) push lambdas into my own select based dispatcher.

[daniele77]

First of all, are you sure boost asio can’t manage file descriptors? Take a look at this page:
https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/overview/posix/stream_descriptor.html

Sorry, but I can’t understand the problem you’re trying to solve in the first place.

Cli handlers all run in the thread that invokes run() on the io_service passed on the cli constructor.
If your application runs in other threads, than you simply needs a way to communicate from one thread to the other.
The right way depends on how works your threads. You wrote that your application has got a dispatcher, so I guess you have a way to send events to it: eg if sending events is an atomic operation / is synchronized, you can safely send events from cli handlers to your dispatcher.
How to reach your dispatcher is another problem again. If you have just one in all the application, you can use the singleton pattern to get the unique instance from inside the cli handlers.