Re: Ada-Oriented GUI

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

On 04/04/2018 00:32, Robert I. Eachus wrote:
> On 4/3/2018 4:31 AM, Dmitry A. Kazakov wrote:
>>>
>>> Strange, this looks a lot like the interface to Text_IO. ;-)
>>
>> Yes, the idea is to have same interfaces.
>>
>>> The File has a controlled part to insure that when the File object 
>>> goes away, the File instance does too, and attempts to call Write 
>>> raise an exception. (Close should do nothing if the File is already 
>>> closed. ;-)  File type is limited to insure that copies are not made.
>>>
>>> What does a blocking package look like?  Much the same, except for 
>>> the name.  You don't need to create a task in the body with an entry 
>>> Write, but that is implementation detail. ;-)  If you want, you can 
>>> replace the task with a protected object to get co-routine semantics.
>>
>> My brain hurts too. I don't understand how this is not blocking. When 
>> Write is called it does not return until I/O is complete. Protected 
>> object or not, the caller is stuck there. Co-routines are supposed to 
>> steal the caller's task and pass it to another thread of control while 
>> awaiting for Write to complete.
>>
>> It is just tasking without time sharing and scheduling.
> 
> I hope we are in full agreement.  We just have a different picture of 
> what the Write procedure does.  So let me provide my version. To get 
> asynch semantics there is a task hidden in the body which has an entry 
> called by Write.  Let's use WT for the task, and WE for the entry. Write 
> will pass its parameters to WE and return.  WT looks like:
> 
>      task body WE is
>      begin
>          ... -- Set up output device.
>        loop
>          select
>            accept WE(...) do
>              ... -- Copy any by reference parameters. No potentially
>                  -- blocking actions please.
>            end WE;
>              .. -- do work here, such as multiple writes to disk.
>                 -- Blocking is not just allowed, it is expected.
>            or accept Close;
>              ... -- Normal file close. Blocking allowed.
>              exit;
>            or terminate;
>          end select;
>        end loop;
>      exception
>        -- Whatever is needed.
>      end WE;
> 
> This task is what does the asynch part of setup, Write, and Close.

No, that does not work. The task must handle multiple I/O operations 
running simultaneously. As an example consider a socket selector that 
handles 1000+ sockets. The goal is to write a thread of control for each 
of the sockets in a way one would do with a blocking socket but without 
1000+ tasks chocking the scheduler.

A socket selector tells its owner which socket can be read/written 
without blocking. The implementation should switch to the co-routine 
handling the socket, read or write a portion of the buffer provided in 
the "blocking" call done by the co-routine. If all buffer read/written 
it passes the control to the co-routine, which then handles the protocol 
a usual sequential way. The co-routine gives control up when it needs 
another portion of data from the socket and does next "blocking" call. 
When the buffer is not completed, the task services another socket and 
another co-routine. This is a kind of light-weight scheduler driven by 
I/O events rather than by clock.

> What happens if you want it to be possible for hundreds of write actions 
> to be pending?  Left as an exercise for the reader.  Hint: requeue ;-) 

No, that does not work either. Requeue re-queues a *task" of the caller 
side. The problem is that there is no task to re-queue.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de