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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 5 Aug 91 15:25:41 GMT From: haven.umd.edu!uvaarpa!software.org!stluka@purdue.edu (Fred Stluka) Subject: Re: Ada and Unix--Blocked Tasks Message-ID: <1991Aug5.152541.21340@software.org> List-Id: In article <1991Jul30.193558.9118@beach.csulb.edu> lewicki@beach.csulb.edu (Dav e Lewicki) writes: > > I have run up against a problem: > > I am working on a program with multiple tasks, one of which makes > a call on the Unix "accept()" routine for sockets. As expected, > the task blocks and waits for a connection. > > But, what I didn't expect is that the other tasks all block too and > the Ada kernel then goes on to complain about deadlock. It seems that > all the tasks are of the same process, so when one blocks, they all > do. The only workaround that I can figure is to poll a non-blocking > "accept()" every 5 seconds or so (yecch). > > Is this a vendor specific problem, or do all Ada/Unix kernals work > this way? I am using the Verdix compiler running on Ultrix. Just as an additional point of data... VAX Ada on VMS has a similar problem. All tasks of an Ada program run in the same process. When a call to a system service causes the process to be blocked, then all tasks are blocked. For this reason, DEC provides a package called TASKING_SERVICES which provides access to the same system services in a mode where only the calling task is blocked. This was easy for them to do because the VMS system services have 2 modes, blocking and non-blocking, and the non-blocking mode can be directed to generate an interrupt when it completes. No polling is required. Non-portable, but it works. --Fred -- Fred Stluka Internet: stluka@software.org Software Productivity Consortium UUNet: ...!uunet!software!stluka 2214 Rock Hill Rd, Herndon VA 22070 USA Voice: (703)742-7236