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: Thu, 22 Mar 2018 10:12:15 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> <858fbe8b-43a2-4ee3-ad51-1d100123a1a3@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:51126 Date: 2018-03-22T10:12:15+01:00 List-Id: On 21/03/2018 23:16, Dan'l Miller wrote: > Dmitry wrote: >> This is not how asynchronous I/O works in >> many cases. The I/O request is >> queued in one thread, initiated in another, >> processed in third, completed in fourth. > > (Other than message-queue-based software architectures,) A great number of protocol stacks work this way. Almost all I/O libraries deploy callbacks on data arrival. Some have the design alike to GUI when you are forced to call something like Do_IO from a thread and get a callback from within Do_IO. But in general nothing in said or required about the contexts of any calls and callbacks. > please name even one async ••system call•• on any OS or OS-framework thereof that requires traversal of those 4 ••app-domain•• threads to produce results (e.g., filesystem read) asynchronously. I don't really know what you mean. Windows overlapped I/O queues a request from your thread. When I/O is initiated it can traverse a number of kernel threads (e.g. Deferred Procedure Call etc). Any number of user-space threads can wait for associated Windows event objects or poll the overlapped I/O result. > What you describe can be a hallmark of message-queue-based software architectures, message-queue software architectures are synonymous with async I/O. No, it is not. Messaging means marshaling. That is not always required or used. Some implementations do in-place I/O by mapping user buffers into the memory if the process margin must be crossed. BTW, Ada's rendezvous model was designed to avoid marshaling. Anyway, as Randy already said, it is incredibly uncomfortable to build the whole application around GUI. The first and foremost requirement for a decent GUI framework is to let us breath. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de