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: 4 Apr 92 19:20:34 GMT
From: widget!jgg@uunet.uu.net  (John Goodsen)
Subject: Re: Ada / X / Motif multi-tasking issues
Message-ID: <1992Apr4.192034.2041@uunet!widget>
List-Id: <comp.lang.ada>

daves@assip.csasyd.oz.au (David Smart) writes:

[... X re-entrancy talk deleted -- see previous articles ...]

>
>Gotta be careful here - it looks as though you're calling Marci's approach re-
entrant.
>

I'm somewhat confused here.  Code one writes might be re-entrant, but what does
it mean to call an approach re-entrant ?

>
>>From what I have seen, the fact that the Ada procedures are implemented as cal
lbacks
>means that X will handle the serialisation of executio.  (After all, it's the 
C part
>of all this that's not re-entrant - not the Ada part - and this is the standar
d way of
>doing it in C.)
>

It's not the callbacks that cause the problems, it's the calls into X
under multiple threads of control (read tasks, threads, whatever).
This *standard* way of doing it in C suffers from the same problems
when you start forking threads which want to talk back to X.  

Also, BTW, one can write just as non-reentrant Ada as C ;-)

>
>I assume that the event to be raised saying that the SQL stuff was ready would
 be
>raised to X, so that the appropriate callback would be executed in the "correc
t" way.
>If so, I see no reason why the work (but not the X calls) cannot be done in a 
separate
>Ada task.                           ^^^^^^^^^^^^^^^^^^^^^
>                                    |||||||||||||||||||||

"but not the X calls" ???  That is the whole problem.  Only one thread of contr
ol
gets to make those X calls at a time.  Possibly the term non-reentrant threw yo
u
off base:

   Non-reentrant-procedure := only one thread of control gets to call it 
                              or else you clobber data.

Not all X calls are re-entrant, hence you don't get to call them from
more than 1 task within a unix process.  Well, I guess you can,
but......  well, shall we say, charge a lot for customer support so
you can handle those customer calls when they start coming in :-)

A solution similar to this (but the exact reverse, if *that* makes any
sense :-) might be to encapsulate the GUI (X-window) portion of the
application in a single task and use task entries to serialize GUI
message passing.

>
>The X calls would then be done from a procedure, packaged with the Ada task,
>but called from the callback routine.
>

Again, the problem is NOT in callbacks, but in X calls made by the application.

>
>> Xt is even less re-entrant.  In fact, Xt will never be re-entrant in
>> it's current design.
>
>> Motif is no more re-entrant (indirectly in part because Xt is not re-entrant
).
>
>The Verdix Ada / SunAda XView bindings allow for concurrent tasks to do XView 
calls
>(we're using it).  We have not tried writing at the X level through these bind
ings,
>however.
>

I while back, a particular binding vendor(s) was saying that they'd
*solved* the Ada tasking problem when in reality, they turned
XtAppMainLoop into a polling loop, but did nothing to serialize the
bindings.  Are you abosolutely sure that the serialization has been
performed in your bindings ?

>
>I imagine that the Verdix Ada Motif bindings (do they exist?) would similarly 
allow for
>concurrent tasks to do Motif calls.
>

AXI (ATC) are the Verdix motif bindings.  I've yet to hear that these
bindings serialize the Motif convenience routines.


>> In other words, multi-threaded applications which have more than 1
>> thread accessing Xlib, Xt, or any other toolkit layered upon Xt are
>> faulty programs.
>
>Not so - see above.  However, remember that the toolkits are not part of the A
da
>language, therefore code written for one must not be expected to be portable t
o others.
>

Yes So!  (I feel like Wayne and Garth :-).  Read the above statement again and 
notice that it is language independent.  multi-threaded means multithreaded, 
regardless if it's an Ada task or a unix fork and regardless if it's Ada, C, Li
sp,
Forth, ....  

>
> IMHO, it is really the task of bindings vendors to develop and maintain
> such tasking safe bindings.
>

Someone needs to do it.  I'd like to see a common interface, so I can port my
application code between compilers, however.  What are the chances that the
compiler vendors will provide a common interface spec on competing implementati
ons
of the bindings ?  Give that it's unlikely, I think the safer choice is to
choose a binding vendor who will gaurantee that they'll cover multiple platform
s
*AND* multiple compilers with the same interface.


>In fact, I see no reason why a standard X, OpenLook and Motif access method ca
n't be
>mandated in Ada 9X.  

I do.  Addressing standard bindings are *NOT* in the charter of Ada9X.
It is a language revision effort.  Binding interfaces have nothing to do
with the language specification.

As always, please redirect your flames to /dev/null   :-)

  % cat flames > /dev/null

-- 
John Goodsen
S/W Development Environmentalist
goodsenj@ajpo.sei.cmu.edu