From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada-Oriented GUI Date: Wed, 21 Mar 2018 18:42:59 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> NNTP-Posting-Host: Ndt9xVy5zYnxU2i8j/ehbw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:51101 Date: 2018-03-21T18:42:59+01:00 List-Id: On 2018-03-21 18:04, Dan'l Miller wrote: > 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). So it is inconsistent unless packed into single thread. No difference, exiting GUI do just same. > Conversely, there is no order to preserve between different single-threaded senders. Surely there is. The order is application level semantics. Threads are possibly implementation artifacts, e.g. worker tasks. (This is a general problem of event-driven architectures. They are non-scalable, non-composable, unstructured and unmaintainable when become large). > 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. I don't see how this is related to GUI design issues, except that when file system I/O indirectly cause GUI events. Then ordering of the events (output-pending, output-complete) must evidently be preserved when used in a progress indicator. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de