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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!bionet!agate!shelby!msi.umn.edu!sctc.com!stachour
From: stachour@sctc.com (Paul Stachour)
Newsgroups: comp.lang.ada
Subject: Re: Ada and Unix Sockets
Keywords: sockets unix blocking
Message-ID: <1990Nov20.205819.24040@sctc.com>
Date: 20 Nov 90 20:58:19 GMT
References: <1873@sirius.ucs.adelaide.edu.au>
Organization: Secure Computing Technology Corporation
List-Id: <comp.lang.ada>

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