Re: Ada-Oriented GUI

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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