From: daves@assip.csasyd.oz.au (David Smart)
Newsgroups: comp.lang.ada
Subject: Re: Ada / X / Motif multi-tasking issues
Date: 6 Apr 92 07:41:23 GMT
Reply-To: daves@assip.csasyd.oz.au
Organization: Computer Sciences of Australia

In <1992Apr4.192034.2041@uunet!widget> jgg@uunet!widget (John Goodsen) writes:
> 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 ?

Alright then ... it looks as though you're calling Marci's approach re-entrant 
programming.

> >From what I have seen, the fact that the Ada procedures are implemented as callbacks
> >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 standard 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 ;-)

Sorry - 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 in a copy
of their parents' environments - that's not re-entrancy.  VMS (for example) does offer
true re-entrancy, which no doubt is supported from within C.

Ada re-entrancy (read - tasking) is standard across operating systems.  (Of course, the
method of implementing tasking within the O/S is not standard, but that's a different
matter.)

Of course it's the calls into X that cause the problems - not the callbacks.  I thought
that was my point.

Marci was saying (I believe) that he had a function which had to go away for a while
and think (or crunch, or something).  He said that it would raise an event flag when it
was finished.  I interpreted that to mean that it could signal when it had the data
ready to be put onto the screen.

As such, this lengthy task involved no X activity, and was a candidate for handling by
a perfectly straightforward Ada task.  The resultant X updates would need to be done
by a task which had synchronised access to the X libraries - therefore my mention of
raising the signal to the X handler and handling the X calls from within a callback
routine.

> >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 "correct" 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 control
> gets to make those X calls at a time.  Possibly the term non-reentrant threw you
> off base:

That's where we differ - I don't believe that that is the whole problem!  As I 
understand what Marci wrote, the whole problem is the delay which will occur between
the originating (mouse?) event and the provision - by the SQL process - of the data
ready for update to the screen.  It is not acceptable, in this instance, for the
program simply to stall waiting for the SQL to complete, Marci wants to do this
asynchronously.

As I see it, Marci identified a method for getting the SQL process to indicate its
completion.  My comments then indicated how this could be used to cause the X updates
to be done without having to resort to re-entrant X calls.

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

I'm sorry - but I do know what re-entrancy is!

> 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 :-)

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

If you're talking Ada, then you're not reading what I said!  I indicated that I was 
currently - i.e. now - using Ada bindings which allow multiple Ada tasks to access
XView (which, of course, rides on X).

> 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.

Sorry, don't understand.  How is the mouse/keyboard interaction going to get done?  X
is not "output-only".

> >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.

And, again, I disagree with you - see above.  (Hope I'm not misinterpreting what you
said, Marci.  If I am, please send size 13 egg-scraper.)

> >> 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 bindings,
> >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 ?

If you mean a polling loop involving application code - yes I'm absolutely sure.

We call the notifier, and don't get control back in that thread until the end.

> >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.

I'm talking about bindings from Verdix, not a third party.  As I indicated, I don't 
know whether Verdix make any, but assumed that - if they did - they would do for Motif
what their SunAda bindings do for XView.

> >> 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 Ada
> >language, therefore code written for one must not be expected to be portable to 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, Lisp,
> Forth, ....  

No.  We are talking Ada here.  And I am talking about specific Ada bindings.

Multi-threaded does _not_ mean multi-threaded!  An Ada task is not the same as a Unix
fork.  Very few languages provide _standard_ support for multi-threading - particularly
across all operating systems.

As an aside, it is probable that a Unix fork (whether running C or Ada parent and child
processes) does not suffer from this multiple thread problem anyway.  As I understand
the problem, it has to do with the use (by the X library) of the program data area for
the storage of essential information.  As the child program gets a whole new data
area, the X library running in the child program will not clobber the data area of the
X library running in the parent program.

Of course, this is not multi-threading.  The two processes do not share data areas,
and do not even run the same program (although the child may start off sharing a copy
of the _instruction_area_ of the parent).

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

Please don't misquote me.  The above paragraph was from your post - not mine.  What I
said was:

"I'd go further, in this day and age.  I believe that X-derivatives are now so common
that people should not consider buying an Ada compiler which doesn't include - as 
standard - a good, and safe, binding for both straight X and the flavour (e.g. Motif)
which is the standard for the target machine."

Your next point seems to be a response to your own comment, with some reflection
on what I said (and you didn't quote):

> 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 implementations
> 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 platforms
> *AND* multiple compilers with the same interface.

This comment (i.e. "common interface") doesn't really fit with your rebuttal of my 
next comment:

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

To which you failed to quote the commonsense rider I placed on the sentence:

"... Provision of actual bindings could still be left optional - simply that if one is
provided it must work in a standard way."

You commented on the first part of the above:

> 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.

Monkeys!  The Ada language standard mandates the way in which computers are programmed
in the language called Ada.  In the standard, there are other items left optional - but
forced to a standard form if included.  There is absolutely no reason why something as
pervasive as X, OpenLook and Motif cannot be dealt with in the standard.

As I indicated - but you chose to omit from your quote - such inclusion should be in
the area of "leave it out by all means, but if you include it, it must be done this
way".

(I wouldn't mind seeing a few other inclusions of this type - f'rinstance index-
sequential files, SQL access method, etc.)

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

Why would I do that - you certainly don't.  :-)

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

I would have hoped to get a little more informed comment - and a little less heat -
from an address like this.  But perhaps you don't have 27 years experience in the
industry, working on computers of almost every size, and in more programming
languages and operating systems than I care to remember.

Memo to Marci: I had intended to provide you with a simple suggestion about a simple
problem you raised.  If I had realised I would get burned alive, I would have sent it
direct.  My apologies.

Dave 
-- 
David Smart, Computer Sciences of Australia.
Net: daves@assip.csasyd.oz.au