Re: Ada multitasking with X-windows

Re: Ada multitasking with X-windows

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!malgudi.oar.net!uoft02.utole]

In article <1992Apr1.183956.29280@flood.com> tom@flood.com (Tom Chatt) writes:
>
>mtabacch@eve.wright.edu (Marci Khader) writes:
>| Subject:  How do you (or would you) implement fork() in Ada???
>| Organization: Wright State University
>| Disclaimer:  All views are my own, and do not reflect the views of SAIC.
>| 
>| Because our group is having a little X-Ada-Unix program in the making,
>| we have the need for another approach.  So, I thought of asking help
>| from people who know alot about Ada.
>| 
>| Heres the problem:
>| 
>| A 'callback' is added to a button (X Window System).  This callback
>| is an Ada procedure.  It must do slow SQL things.  We do not want the
>| GUI to wait for this to complete.  Instead, we want (through some
>| mechanism in Ada) the procedure, task or ???? to do its thing, and
>| then send raise an event 'got_SQL_stuff_event' to the GUI. 
>| 
>| In 'C' you could do a fork with the parent not waiting for the
>| child to finish.  
>| 
>| Insights, thoughts, criticisms are welcomed, encouraged but will not
>| be paid for except by our undying gratitude!
>
>You would be well-served to put the SQL stuff in a separate Unix process,
>i.e., a database request server. This server is an Ada back-end program
>with no GUI, merely handling IPC requests for a query and sending back
>IPC responses with the results. (It might use X merely for IPC, or you
>might just use sockets.) Then your Ada GUI program only has to deal
>with the GUI, and with fielding the IPC responses, which you can do
>without trouble, in X.
>
>Use Unix processes to deal with the concurrency.
>
>jgg@evb.com (John Goodsen) writes:
>|
>| X/Ada developer BEWARE!
>
>And goes on to warn about the dangers of X and Xt non-reentrancy.
>He is right on. However, if you have only one task dealing with the
>GUI and your other tasks are doing "back-end" things, you may be
>able to successfully use the Ada tasking model to deal with your
>concurrency.
>
>-- 
>Tom Chatt                        \   Don't take offense, take action.
>Internet: tom@flood.com           \    Speak up. When we remain silent,
>UUCP: ...!uunet!flood!tom        / \     we oppress ourselves.


Thanks for the suggestions and valuable insight.  Appealing and elegent
as it may be, using Unix processes to implement the concurrency is
a no-no, in light of the portability aspects.  In my note, I did not
elaborate on additional details (like future necessary ports, and 
signal handling between parent and child, in the case of fork()).
So, John's suggestion, and Tom's confirmation (along with many other
respondants) is well taken.  There are still some details concerning
the 'serialization of tasks' performing X calls.  Put all of the
GUI type calls in one task you say?  Or use semaphores on all X calls?
What are your thoughts about this?


marci

Re: Ada multitasking with X-windows

[Xmiester]

dwb@IMD.Sterling.COM (David Boyd) writes:

[... read earilier news posts on comp.windows.x to get the preliminaries ...]

>
>	And the government wants to know why developing X applications
>in Ada costs so much!!  
>
Compared to what?  Who has been doing this complaining?  I've been
searching for this information, but have yet been able to find any.

>I am old enough to remember the tail end of JOVIAL
>(a previous government developed language) and someone asking us to develop
>bindings between our FORTRAN libraries and JOVIAL.  The problems were very
>similar and the solutions equally ugly in many cases and JOVIAL was not as
>different from FORTRAN as Ada is from C.  
>

The currently available commercial Ada/Motif bindings can hardly be
called ugly.  They are as clean (or cleaner) than the C interface
with stronger type checking.  (Can you say "pragma External" ?)

>
>	The solution is for someone to
>completely re-implement not only the X library and intrinsics with a
>design geared toward Ada but the GUIs libraries (OLIT & MOTIF) as well.
>

I hardly believe this is a cost effective solution.  The answer is *NOT*
to re-invent a *better* wheel w/o a justification for the cost.  The
majority of Ada projects can deal with non-reentrant X/Xt/Motif libs.
It just requires knowledge and good design to do it right.  I suggest
that a better spent dollar is in the training of Ada engineers on the
issues and how to deal with them effectively from an engineering standpoint.
(It's surprising how many Ada programmer's I meet who write multi-tasking
 software, but don't understand the issues involved in writing re-entrant
 code, providing tasking-safe data structures, or real-time software in
 general).


I've been involved in the proposed design for an Ada widget set.
It ended up coming surprisingly close to the Xt single inheritance
model minus the added features of Xt/Motif such as the event translation
manager, keyboard traversal, etc... (due to $$$ considerations :-)

(BTW, the Ada9X inheritance proposal is a near duplicate of
the Xt single inheritance model -- It's how we've done it for years
in a more formalized definition, that's all).  Not that I'm saying the
Xt inheritance model is *great* but it's how you do it by hand in
a language which doesn't support inheritance.  (ie. it's optimally sufficient)

MOTTO: Do not what has been done, but understand it and use it.


-- 
John Goodsen
goodsenj@ajpo.sei.cmu.edu

-- 
John Goodsen
goodsenj@ajpo.sei.cmu.edu

Re: Ada multitasking with X-windows

[deccrl!news.crl.dec.com!hollie.rdg.dec.com!player.enet.dec.com!vanavermae]

with standard_disclaimer; use standard_disclaimer;

I think a number of issues have been confused in the heated discussion that
followed.

The first issue was that X and Xt are not thread-safe - you have to make all
calls from one task.

The same is probably true for (the implementation of) SQL (but I do not think
that any particular SQL implementation was ever mentioned).

Another (potential) problem that was not mentioned is that it might be a bit
difficult to reconcile XtMainLoop with Ada tasking - but I have no experience
with this.

An issue that WAS mentioned, is that the developer wanted the X application to
continue to function while the SQL operation was in progress. The problem there
would be, that when a software layer (e.g., an SQL implementation) blocks a
task, it might block the whole process (it depends, I suppose, on that software
layer, on your operating system, and on the implemntation of the Ada run-time
system).

Some people have suggested separating this into 2 processes - I would agree. Th
e
client would do the X stuff, and the server would do the SQL stuff. They could
communicate through a pair of pipes (Unix) or a pair of mailboxes (VAX/VMS). Yo
u
would have to prevent the client from blocking (the whole process) while
performing operations on those pipes/mailboxes - but that should not be too
difficult. This solution would not be identical for the different platforms (th
e
author of the original note did not mention which platforms he had in mind), bu
t
it would be similar - and the differences could probably be confined to a coupl
e
of package bodies.