Re: Ada-Oriented GUI

["Dan'l Miller" <optikos@verizon.net>]

On Wednesday, March 21, 2018 at 11:27:56 AM UTC-5, Dmitry A. Kazakov wrote:
> On 21/03/2018 15:30, Dan'l Miller wrote:
> 
> > Rx is directly aiming at solving that entire problem space.  Quite well, btw, especially regarding concurrent scheduler-based handling events arriving haphazard from drastically-different concerns:  human GUI events, application lifetime events, network traffic arrival events, asynchronous OS events (e.g., filesystem I/O), and so forth.
> 
> Scheduling implies that order of events is not preserved, right? How 
> consistency is achieved?

The order of each sequence of events from a single-threaded sender is strictly preserved in Rx (including under the numerous filtering mechanisms).  Conversely, there is no order to preserve between different single-threaded senders.  E.g., async filesystem I/O events can interleave GUI human-activity events can interleave application-lifecycle events can interleave network packet-arrival events arbitrarily and differently each execution.  Having a software architecture that obfuscates this natural lack of any inter-sender ordering is what causes deep & severe & pernicious bugs (actually worse that bugs, usually fatal-to-the-feature back-to-the-drawingboard nonrealtime design flaws and much head-scratching).  Having a software architecture that effectively says, “Hey, we've done the heavy lifting of flowing all these rivers of data to you without ruining them; now you need to do the hey-dummy-don't-ruin-them-by-comingling-them-illogically too, such as implicitly expecting a GUI event to arrive ahead of a network packet or vice versa, or implicitly expecting an app-lifecycle event to never arrive before an async filesystem I/O event.”  Rx brings •composable system• to realtime event arrival by (nearly-)demanding that the arbitrary-order events are blatantly obvious *between* different sequences (by making the preserved-order events blatantly obvious *within* any one sequence).