bradley@chook.adelaide.edu.au (Bradley Schmerl) (11/19/90)
Greetings, 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? Oh, I am using Verdix Ada 5.5 on an Encore MultiMax under Unix. Could you also e-mail me directly, as I don't read this newsgroup often. Bradley. -- bradley@cs.adelaide.edu.au
stachour@sctc.com (Paul Stachour) (11/21/90)
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
dennis@tfsg.UUCP (Dennis Gibbs) (11/26/90)
In article <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? > > Bradley. > bradley@cs.adelaide.edu.au Bradley, Could you email me the replies you get to your posting to comp.lang.ada regarding Ada and Unix Sockets? We are experiencing the same exact problem (Ada tasks get blocked while waiting for events) and I don't know yet how to solve this either! Any replies you get that you could send me would be most appreciated...Meanwhile if I uncover any solutions I'll send them your way.... Thanks! Dennis Gibbs TRW Systems Integration Group (703) 802-1961 ...uunet!tfsg!dennis P.S. I tried email to you but it bounces.....
alliot@enac5.enac.dgac.fr (Jean-Marc Alliot) (11/30/90)
Our news system broke off last week and I didn't get the address of the poster of the query. So I'm posting this answer directly to the net. We experiened the same rpoblem using ADA-ALSYS compiler and UNIX sockets on a SUN (3.5, 4.0 and 4.1 OS). The reason is quite easy to understand. Every ADA task belongs to the same UNIX process. And any system call (like read, write or accept) is blocking (by default), and blocking for the WHOLE UNIX process. So every task is automatically blocked. Solving completely the problem was quite difficult. We had to mask the UNIX OS, and it ended in more than 5000 lines of ADA code. The packages are now efficient and probably portable on any BSD-based system.