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: 3 Apr 92 18:25:35 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!malgudi.oar.net!uoft02.utole
do.edu!desire.wright.edu!eve.wright.edu!mtabacch@ucbvax.Berkeley.EDU  (Marci Ta
bacchi)
Subject: Re: Ada multitasking with X-windows
Message-ID: <1992Apr03.132530.25081@eve.wright.edu>
List-Id: <comp.lang.ada>

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