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: 2 Oct 92 06:34:09 GMT From: cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!goodsenj@uunet.uu.ne t (John Goodsen) Subject: Re: Ada's (in)visibility Message-ID: <1992Oct2.063409.3456@sei.cmu.edu> List-Id: emery@Dr_No.mitre.org (David Emery) writes: > >>To be fair Xlib is not suitable to mulitasking and most large Ada systems use >>tasking. There is no good solution to this problem yet. > >There is a very good solution to this. Don't use tasks. Write >sequential Ada. This provides EXACTLY the same kind of program you >would get if you wrote the application in C. > This is a poor solution. It is quite feasible to use Ada tasking with Xlib applications, however, you must design the application up front to ensure that only a single thread is making Xlib calls up front. The problem gets harder if you attempt to address the potential for deadlock within a task caused by a callback into the application. In this case, you need access to the task id to ensure you don't lock out the same thread more than once. See the Xhibition 91 conference proceedings for a paper on this subject. >Just because Ada has >tasking, there is no obligation to use it in any specific application. >I'm always bothered by people who use lack of support for Ada's >advanced featuers to write a program in C that can be done in >equivalent Ada (without tasking, for instance). > > >An true Ada binding to Xlib should handle the tasking issue (perhaps >by abstracting a kludge). This is one of the things that makes doing >good Ada bindings non-trivial. If someone tries to sell a "binding" >to Xlib that does not handle tasks, he's not selling a binding. >Instead, he's selling PRAGMA INTERFACE(C), without doing any of the >real work. > There do exist commercial bindings which are thread safe for the Verdix Ada compiler in Xlib applications. > >The real solution for Ada and X Windows will occur when X Windows is >multi-threaded in a way that meshes with Ada tasks. Xlib will never be multi-threaded, however, there is a high probability that R6 will support multiple threads (unix threads), by using extending the null locking macros to be a complete implementation. This will only make Xlib thread safe, not multi-threaded in it's own right. In addition, this doesn't necessarily mean that it will be *safe* to use with Ada tasks, unless an Ada task maps directly to a unix thread. Because of this, you must rely on tasking safe bindings which perform the locking or use an Ada toolkit, like GRAMMI which directly addresses and solves the multi-tasking problem. John Goodsen goodsenj@ajpo.sei.cmu.edu