comp.lang.ada
 help / color / mirror / Atom feed
From: wilson%anchor.DECnet%lll-icdc.arpa%taurus.BITNET@WISCVM.WISC.EDU ("ANCHO)
Subject: Pre-elaboration Problems
Date: Mon, 29-Dec-86 22:27:00 EST	[thread overview]
Date: Mon Dec 29 22:27:00 1986
Message-ID: <8701010304.AA21165@ucbvax.Berkeley.EDU> (raw)

I have run into a problem with Ada and both of the solutions I have found
bother me.

I have a generic package which a user (i.e., programmer) can use to easily
perform DECnet network I/O.  The package can support many similtaneous
I/O channels.  The package imports a MESSAGE_TYPE and a HANDLE_MESSAGE
procedure and exports an ADDRESS_TYPE and a SEND procedure.  Here's the
spec.:

        package NET_READER is

            type ADDRESS_TYPE is private;

            generic
                type MESSAGE_TYPE is private;
                with procedure HANDLE_MESSAGE(
                                        FROM    : in ADDRESS_TYPE;
                                        MESSAGE : in MESSAGE_TYPE
                                             );

            package READER is

                procedure SEND(
                                TO      : in ADDRESS_TYPE;
                                MESSAGE : in MESSAGE_TYPE
                              );

            end READER;

        private . . .

        end NET_READER;


The idea is that the package user just needs to supply a HANDLE_MESSAGE
procedure and all the network stuff will be taken care of for him.  It is
expected that HANDLE_MESSAGE will sometimes call SEND to send a reply back
to the originator of the current message.

The user program looks something like this:

        with NET_READER;

        procedure TEST is

            procedure HANDLE_MESSAGE(
                        FROM    : in NET_READER.ADDRESS_TYPE;
                        MESSAGE : in MESSAGE_TYPE
                                    );

            package NET is
                new NET_READER.READER( INTEGER, HANDLE_MESSAGE );

            procedure HANDLE_MESSAGE(
                        FROM    : in NET_READER.ADDRESS_TYPE;
                        MESSAGE : in MESSAGE_TYPE
                                    ) is

            begin

                ... NET.SEND ...

            end HANDLE_MESSAGE;

        begin null; end TEST;

The problem is this:  if a message is "waiting at the door," HANDLE_MESSAGE
gets called before it is elaborated, resulting in a PROGRAM_ERROR.  This is
because the declarative part of TEST is elaborated in top-to-bottom order.
Unfortunately, HANDLE_MESSAGE needs visibility of NET to call SEND.

My solutions are these:

        1)  Put a loop and an exception handler in the body of
            NET_READER.READER and wait for PROGRAM_ERROR to go away.

        2)  Put a START procedure in NET_READER.READER which the user
            has to call to start things up.

Solution 1 is a problem for a few reasons.  Should the loop be infinite?
How long should we wait?  What if the user's HANDLE_MESSAGE routine is
raising another kind of PROGRAM_ERROR and we're just getting a propogated
version?  The nice side of this way is that all the messy details are
hidden in the package body.  The user couldn't care less about the order of
elaboration, and likely won't understand the problem in the first place.

Solution 2 has the problem of requiring explicit action on the user's
part.  START looks like an initialization routine, and in all the rest of
our packages initialization is done inside the package.  Asthetically, we
loose the "begin null; end" main program body which has looked so
appealing.

A more general problem is one where the generic package imports a user
routine and doesn't export anything.  In this case, the user could order
his declarative part such that the package instantiation comes after the
procedure body, but *I* wouldn't have naturally done that anyway.  I'd have
made the forward declaration of my procedure just so all my declarations
would appear together on a small page.  Then, everything would have worked
nicely until the window was hit a few months down the road . . . .

My questions to the Ada community are these:

        o  Is there a Solution 3?

        o  Can anyone make me feel better about Solutions 1 or 2?

        o  How can I convince myself that my program isn't some day going
           to call an unelaborated routine?  Is there a simple checklist
           I can use?

Finally, why don't I get a PROGRAM_ERROR on the following program?  It seems
like as soon as the main task has elaborated task T, T should start running
(given the higher priority) before P is elaborated . . . .
(I compiled and ran this using VAX Ada on a VAX 11/750.)

        with TEXT_IO;   use TEXT_IO;
        with SYSTEM;

        procedure TEST_1 is

            task T is
                pragma PRIORITY( SYSTEM.PRIORITY'last );
            end T;

            procedure P;

            task body T is
            begin  P;  end T;

            procedure P is
            begin  PUT_LINE( "Hi!" );  end P;

        begin null; end TEST_1;

Thanks for your interest,

                        --- Rick Wilson

wilson%anchor.decnet@lll-icdc.arpa
(415) 423-6662
------

             reply	other threads:[~1986-12-30  3:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1986-12-30  3:27 "ANCHO [this message]
  -- strict thread matches above, loose matches on Subject: below --
1986-12-30  3:27 Pre-elaboration Problems "ANCHOR::WILSON"
1987-01-05 22:25 ` Arny B. Engelson
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox