right compilation unit for C as main?

right compilation unit for C as main?

[Patrick]

Hello 

I am trying to run concurrent Ada code bound to a C main.

I can get the Ada side to run if I explicitly call a procedure but I just want it to start running on adainit() and not block C untill it completes . I tried to write the Ada code inside a task but I ended up with an error that a task body is not a compilation unit.

is there someway to have C main looping through C code and have an Ada task running or do I have to call C as a task? I would prefer to have C as main as some libraries seem to expect to be called from it.

Thanks for reading

Re: right compilation unit for C as main?

[Brian Drummond]

On Tue, 18 Dec 2012 07:02:25 -0800, Patrick wrote:

> Hello
> 
> I am trying to run concurrent Ada code bound to a C main.
> 
> I can get the Ada side to run if I explicitly call a procedure but I
> just want it to start running on adainit() and not block C untill it
> completes . I tried to write the Ada code inside a task but I ended up
> with an error that a task body is not a compilation unit.

adainit() should not block! It should set the environment up for Ada and 
return to your C main program. Which will then call an ...ahhh, Ada 
procedure which WILL block because the tasks it creates cannot outlive 
it...

So this Ada procedure must create your Ada tasks, and then execute a C 
function from its procedure body - your actual C code lives here.

But given this structure I don't see why you don't just use an Ada main.

> is there someway to have C main looping through C code and have an Ada
> task running or do I have to call C as a task? I would prefer to have C
> as main as some libraries seem to expect to be called from it.

If there is something odd about setting up some C libraries, then perhaps 
you can do this from a C main, then call the Ada procedure described 
above.

- Brian

Re: right compilation unit for C as main?

[Patrick]

Thanks Brian

You saved me a lot of hair pulling. I will just try to use an Ada main again.

Have a great day

Re: right compilation unit for C as main?

[Robert A Duff]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> adainit() should not block! It should set the environment up for Ada and
> return to your C main program. Which will then call an ...ahhh, Ada
> procedure which WILL block because the tasks it creates cannot outlive
> it...

That's true only if it declares objects containing tasks.
If it allocates objects containing tasks via "new",
with the access type declared at library level, then the
tasks can outlive their creator.

Tasks can also be created during library-package elaboration,
which is called from adainit.

> So this Ada procedure must create your Ada tasks, and then execute a C 
> function from its procedure body - your actual C code lives here.
>
> But given this structure I don't see why you don't just use an Ada main.

Using an Ada main is usually easier, but using a C main is
also possible, and sometimes necessary for reasons outside
the Ada world.

- Bob

Re: right compilation unit for C as main?

[Robert A Duff]

Patrick <patrick@spellingbeewinnars.org> writes:

>...I tried to write the Ada code inside a task but I ended up with an
>error that a task body is not a compilation unit.

Right.  You declare library packages, and put your task types and bodies
inside those packages.

- Bob

Re: right compilation unit for C as main?

[Brian Drummond]

On Tue, 18 Dec 2012 12:13:40 -0500, Robert A Duff wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> adainit() should not block! It should set the environment up for Ada
>> and return to your C main program. Which will then call an ...ahhh, Ada
>> procedure which WILL block because the tasks it creates cannot outlive
>> it...
> 
> That's true only if it declares objects containing tasks.
> If it allocates objects containing tasks via "new",
> with the access type declared at library level, then the tasks can
> outlive their creator.

Thanks for the correction; it may give Patrick another option. (Though 
declaring tasks within the Ada procedure looks easier to get right - at 
least for a relative beginner like myself.

- Brian

Re: right compilation unit for C as main?

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Tasks can also be created during library-package elaboration,
> which is called from adainit.

This is one of the few ways I've managed to cause elaboration-order
problems with GNAT's default elaboration order algorithm.

Re: right compilation unit for C as main?

[Niklas Holsti]

On 12-12-19 05:04 , Simon Wright wrote:
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
>> Tasks can also be created during library-package elaboration,
>> which is called from adainit.
> 
> This is one of the few ways I've managed to cause elaboration-order
> problems with GNAT's default elaboration order algorithm.

That happened to me, too. I got around the problems by putting all
library-level tasks in packages that have no public (provided)
interface, so that these packages can be elaborated last. I usually
"with" these "task packages" only from the main subprogram.

Separating the tasks in this way also helps unit and integration
testing, because one can then build the program with any desired subset
of the tasks just by changing the "with" clauses in the main subprogram.

The converse drawback is that the absence or presence of tasks in some
subsystem is revealed at the highest design levels, instead of being
nicely hidden and encapsulated in the subsystem. Another result of this
design style is that it becomes difficult to use task entries and
rendez-vous, because of the rule that allows accept statements only in
the body of a task and not in subprograms called from the task. So I
tend to use only protected object entries.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: right compilation unit for C as main?

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>
>> Tasks can also be created during library-package elaboration,
>> which is called from adainit.
>
> This is one of the few ways I've managed to cause elaboration-order
> problems with GNAT's default elaboration order algorithm.

Yes, that's a problem.  One solution is to use pragma
Partition_Elaboration_Policy, so library level tasks are
not activated until after all the library units have been
elaborated.

- Bob