Re: Ada and Unix--Blocked Tasks

[milo!drew@uunet.uu.net (Drew Johnson)]

>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