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,FREEMAIL_FROM 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: "Robert I. Eachus" Newsgroups: comp.lang.ada Subject: Re: Ada-Oriented GUI Date: Tue, 3 Apr 2018 18:32:45 -0400 Organization: Aioe.org NNTP Server Message-ID: References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> <656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com> NNTP-Posting-Host: fZYVf2g/avGnWJvs1xVPEA.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 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:51325 Date: 2018-04-03T18:32:45-04:00 List-Id: 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.