From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 6 Aug 91 14:57:27 GMT From: milo!drew@uunet.uu.net (Drew Johnson) Subject: Re: Ada and Unix--Blocked Tasks Message-ID: <1991Aug6.145727.9588@verdix.com> List-Id: >In article <1991Aug6.040550.785@beaver.cs.washington.edu> mfeldman@june.cs.was hington.edu (Mike Feldman) writes: >>In article <780@esosun.UUCP> howard@hulder.css.gov (Howard Turner) writes: >>> >>> [stuff deleted] >>> >>> "Tasking IS a part of Ada." But it is not a part of the >>>OS (usually). The OS (except for maybe Rational's) has no notion >>>of Ada tasking, so why would you expect it not to block the entire process? >>>In particular, Ada tasking is not a part of either VMS or Unix. Neither >>>OS will recognize the difference between an executable generated from C or >>>Ada or any other language. Why would you expect the OS to handle executable s >>>derived from Ada source any differently than from C? >>> >>> [more stuff deleted] >>> >>What Paul might be getting at is the notion that an Ada compiler could >>(should) map each Ada task onto an OS-level process. I see no reason in >>principle why this could not be done; indeed, I think there may be vendors >>who are doing it in Unix (can anyone confirm this?). I believe I heard >>that one of the MVS (IBM mainframe) Ada systems can map Ada tasks to MVS >>tasks (can anyone confirm?). In practice, I imagine that vendors are >>keeping an ada program - tasks and all - in one OS-level process for >>efficiency, reasoning that mapping tasks onto processes is overkill. >> >>This is an area where I'd love to see some material that would let us in >>on some of the "inside" discussions that must have taken place over the >>years. Norm Cohen? Tucker Taft? Bob Eachus? How did the designers >>imagine the (possible) relationship(s) between tasks and processes? I believe that Alsys allows you to specify that a task run as a separate process under Unix -- I do not know what restrictions apply however. There are 2 main problems with mapping tasks to processes under Unix: rendezvous and data-sharing. The performance cost of implementing these features is very high. Rendezvous is basically just a time sink, but shared-data is a time and space sink. For shared data, there would be only 3 ways that I can think of to implement it: 1) allocate a shared memory segment to store all global data -- this works for static objects, but under Unix, shared memory segments are of fixed size. Dynamic allocations would be very hard to manage. This gets very ugly when you have alot of Ada programs running at once. Access to all of the data in this area would have to be protected as well -- a significant performance hit. 2) Use memory-mapped files -- this has the same drawbacks as (1). 3) Generate some sort of IPC calls to a kernel-like process managing all shared data -- this one is too ugly to even think about :). What is really needed is a solid, complete thread implementation. I understand that Mach has or will have this, and some Unix vendors are slowly migrating toward this. Full thread support would mean that most system calls would block a thread within a process, not the entire process. Then Ada vendors can map Ada tasks to threads and everyone is happy. As for non-blocking IO, there is no LRM requirement that text_io.get cause a task to suspend until the get can complete. Unless pre-empted by a higher priority task, this task should be allowed to run until it either terminates or suspends due to an entry call, an accept, a delay, etc. It is perfectly legal to function in this matter. Now I agree that there is often a big difference between what is technically legal and what the customer wants/expects. However, in order to implement non-blocking IO in Unix, your process must either catch and handle SIGIO, or it must poll the descriptor. Polling can be very expensive from an execution standpoint, and can possibly result in data loss, depending on the IO device driver involved. Using SIGIO maintains the efficiency, but since no Unix that I know of guarantees that signals are 100% reliable, this might not be desireable for some users. The biggest problem with using SIGIO to provide non-blocking text_io is that many users want to use non-blocking IO for other forms of unix IO (such as sockets). Now there is a conflict between the application and the runtime because both want to monopolize a single resource. This can be gotten around by having the vendor provide routines to interface to SIGIO handling, but this makes code alot less portable. IMHO, the best solution to this situation is the standardization of package POSIX_IO. I believe that this package provides all the necessary functionality to perform non-blocking IO, and would then be very portable. Drew Johnson, Product Support Verdix drew@verdix.com