Re: Ada's (in)visibility

[cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!goodsenj@uunet.uu.ne t (John Goodsen)]

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