Re: Ada / X / Motif multi-tasking issues

Re: Ada / X / Motif multi-tasking issues

[John Goodsen]

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

Re: Ada / X / Motif multi-tasking issues

[Xmiester]

response to daves@assip.csasyd.oz.au (David Smart) innaccurately reverse-flames
:

[irrelevant nonsense deleted...]

>
>Are you talking C or Ada here?  I'll assume Ada, as Unix/C doesn't allow light
weight
>tasking as standard, as I understand it.
>

Just because tasking is part of the Ada language spec doesn't make it
any more sacred. (BTW, I use Ada tasking and like it :-)  You are
sending the wrong message in your response that it's ok to use tasks
and not think about the design of the software because -- "Hey!  It's
Ada.  It'll take care of everything for me!"  -- wrong answer, as I'll
point out below...


>
>what *standard* way of doing it in C?  As I see it, Unix offers no standard
>re-entrancy at all.  It does offer forks, which are child processes, running i
n a copy
>of their parents' environments - that's not re-entrancy.  VMS (for example) do
es offer
>true re-entrancy, which no doubt is supported from within C.
>

This is not a correct set of statements.

Note the "quoted" use of the term *standard*.  There are several 
implementations of light-weight threads in Unix (eg. what is Mach 
for an example).

In what VMS manual does DEC claim "true re-entrancy" ?  One can write 
non-reentrant software just as easy in VMS as in Unix or any other 
system which will allow one thread of control to interrupt another 
thread of control within the same address space.


>
>Ada re-entrancy (read - tasking) is standard across operating systems.  (Of co
urse, the
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            NOT TRUE !!!


I believe this confirms the fact that you are not understanding the
term "re-entrant".


I'll try to explain one last time:

Here's a more direct example:

consider the following *package* (just typed it in, won't compile as is)
it's ugly, but I hope it gets the point across:

--------------------------------------------------------------------

package body Non_Reentrant_Code is


  --
  --  First some unprotected package state data for us to muck with
  --
  the_values : array ( 1..some_very_huge_integer ) of Float ;
  the_index  : integer ;


  --
  --  then a procedure to muck with it
  --
  procedure Load_The_Values is

  begin

    for the_index in the_values'RANGE loop

      the_values(the_index) := some_random_value ;

    end loop;

  end Load_The_Values ;


end Non_Reentrant_Code ;


-------------------------------------------------------------------------------
-


Ok, now go out and create many tasks and have them start calling the
procedure:

  Load_The_Values

What happens when task X starts filling up the array and changing the
value of "the_index", then gets interrupted by task Y to who start's
filling up the array and *ALSO* changing the value of the "the_index"?
The procedure Load_The_Values is known as non-reentrant.

See the problem now ?

Hence, an example of reentrant code is code which *CAN* be executed
from more than one thread of control at a time.  The above design is
not multi-threaded safe and the Ada code is *NOT* reentrant regardless
of operating system.  (assuming interruptable tasks are implemented by
the Ada RTS).


>
>what *standard* way of doing it in C?  As I see it, Unix offers no standard
>re-entrancy at all.  It does offer forks, which are child processes, running i
n a copy
>of their parents' environments - that's not re-entrancy.  VMS (for example) do
es offer
>true re-entrancy, which no doubt is supported from within C.
>

Not true.  Re-entrant code is a design issue, not a language or
operating system issue.


Was that nicer ?  I really tried hard not sound as if I was flaming,
however, if you're gonna put statements out in public, you gotta
be able to take the heat when they're wrong...in particular, I don't
care to be reversed-flamed with mis-information :-)

If the oven's too hot, don't stand in the kitchen.

I suggest a followup to /dev/null, unless the flame content is worth
net band-width.





John Goodsen

with Standard_Disclaimer; Use Standard_Disclaimer;

widget!jgg@uunet.uu.net
^^^^^^^^^^^^^^^^^^^^^^^
Feel better ?


--