Re: Ada-Oriented GUI

["Robert I. Eachus" <rieachus@comcast.net>]

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.  The 
setup actions take place at the begin corresponding to the declarative 
part containing the task declaration.  Write calls WE, any necessary 
copies are done, and the actions following the accept alternative for WE 
happen in parallel to the main program.

If you want pure co-routine semantics, move the code following end WE; 
just before it.  Wrap the code following Close in a do...end Close; and 
finally, move the code after the begin into the (generic) package.  When 
you test that version, either the main program should be running, or the 
task, or they should be in a rendezvous.  Single thread of control, 
swapped back and forth.  As I pointed out in the original post, you 
could replace the task with a protected object.

Technically, an implementation could implement the protected object as a 
task.  Notice that all of the potentially blocking actions above are not 
inside the accept statement.  In practice we expect compilers to run 
short bits of glue code from protected objects in the thread of the 
caller.  Why make the compiler writer's job harder by putting 
potentially blocking code in what looks like glue code?

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 ;-) 
Note that if I was grading this homework, I would take a lot of points 
off for not limiting the size of the queue.  Whether the number 
permitted to be waiting was 100, 1000, or whatever would not be that 
important.  Testing to find the value that works best is extra credit.