Doing Everything Asynchronously

[LegalizeAdulthood]

I've been thinking about this for a while.

The current architecture of trn is to perform operations synchronously, for the most part. While displaying an article, there is some background processing that happens, but for the most part the user waits for all network communication to complete before they can interact with a news server at any given stage.

For instance, when first connecting to a server, trn gets the active file and so-on to determine the list of available newsgroups, prompt you for new groups to add and display article counts for groups.

Things get more interesting if you define multiple remote sources in your access file.

We should be able to do a bunch of things in advance while you are sitting at a selector prompt or reading an article. Specifically:

• Multiple concurrent connections should be established to each news source in your access file
• Process KILL file, scoring and other article actions concurrent with user interaction
• Handle user input as just another concurrent input source

Now "concurrent" here could just mean a single-threaded approach with asynchronous operations happening on a single boost.asio I/O context. Given the way global variables are used in trn, this seems the easiest route to approach first.

However, there's no reason that a single news client can't establish multiple NNTP connections to a single server, or if using the filesystem, process multiple files concurrently. You have to be careful with multiple NNTP connections because there is some implied state that is set by commands, e.g. the "current newsgroup" and the "current article". However, if you have one connection dedicated to whatever the user is reading at the moment and other connections dedicated to "look ahead" processing, e.g. KILL file and scoring of articles yet to be read. Obviously this would mean that shared state would need to be updated by the different connections, but while everything is happening asynchronously, it's not happening multi-threaded, so no locking would be needed around existing data structures, just coordination between IO processing.

Obviously this would be a huge change to trn's code base and would require a lot more than just the sprinkly bits of boost.asio that I've already introduced, so it wouldn't happen for trn 5.0. However, I do think this would make for a very interesting project even in the single-threaded incarnation, so I may attempt it at some point.