From: stachour@sctc.com (Paul Stachour)
Subject: Re: Ada and Unix Sockets
Date: 20 Nov 90 20:58:19 GMT [thread overview]
Message-ID: <1990Nov20.205819.24040@sctc.com> (raw)
In-Reply-To: 1873@sirius.ucs.adelaide.edu.au
bradley@chook.adelaide.edu.au (Bradley Schmerl) writes:
> I am writing a program in Ada which uses a blend of X events
> and socket communication with other ada programs. I am running into
> a problem doing this, because when a call is made to wait for a socket
> (or get the next X Event), the whole Ada program (only one Unix process)
> blocks, and so other tasks don't continue running. Is there any way
> of overcoming this problem, apart from using
> a busy loop to continually poll for events?
> Could you also e-mail me directly, as I don't read this newsgroup
> often.
This is a rather "standard" problem. One has to begin by
thinking in a concurrent mode. We note that many OS'es don't
have tasks (e.g., MSDOS) and others don't have threads(e.g, most unixes).
What you are looking for is an OS that has threads (also-known-as
thin or weak processes) and and Ada Compiler that implements each
task as a thread.
Any Ada compiler builder has a dilema to overcome, namely:
"Is an Ada Task a OS Process or not?"
If the answer is "Yes", i.e., an Ada task is an OS process, then:
In some OS'es, there is a problem of sharing memory.
In some OS'es, there is an interrupt handling problem.
In some OS'es, the context-switch it too long.
In some OS'es, one can't implement certain rendesvous cheaply.
If the answer is "No", i.e., a whole Ada program (multiple Ada tasks)
is one OS process, then:
In some OS'es, there is a blocking of all tasks when a program
does IO.
In some OS'es, there is a blocking of all tasks when a program
does an OS Service call.
In some OS'es, there is a blocking of all tasks when a program
calls some service subprogram that ... [Your case]
Let's face it, most interfaces are NOT designed in an asynchronous
manner, where one sets-off a request, and then checks-back to
see if it is done. [The IO requests in IBM's OS/360 and followon
lines are a good example of doing it "right" from a tasking
point-of-view, but it is OS/MVT].
Stepping back a moment, does the Ada compiler vendor have a
responsibility to ensure that ALL subroutines you call from
your Ada program behave responsibly? No, that responsibility
is only for TEXT_IO and other native-Ada packages.
What would I do? Given that the subroutine is non-Ada (if it is
Ada then the subroutine implementor has a duty), I would have
to step-out of Ada and create another OS-process. I then need
that OS process to issue the sockets [or whatever] call; thus
blocking. And have it send my Ada program a message with the OS
message service, or use shared memory, or something similar,
when the service was completed.
...Paul
--
Paul Stachour Secure Computing Technology Corp
stachour@sctc.com 1210 W. County Rd E, Suite 100
Arden Hills, MN 55112
[1]-(612) 482-7467
next prev parent reply other threads:[~1990-11-20 20:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1990-11-19 4:15 Ada and Unix Sockets Bradley Schmerl
1990-11-20 20:58 ` Paul Stachour [this message]
1990-11-21 16:05 ` Ada and OS tasks (was Ada and Unix Sockets) Jerry Callen
1990-11-23 13:19 ` Ada and OS tasks Jean-Loup Gailly
1990-11-26 12:34 ` Ada and Unix Sockets Dennis Gibbs
1990-11-29 22:59 ` Jean-Marc Alliot
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox