Difficult to describe problem

Difficult to describe problem

[Nige]

Hi - Sorry about the ambiguous title of this post, but it's hard to sum 
up the problem.

What I have is a simple Ada interface to the Xlib function which 
contains functions for creating windows, and drawing in them, etc.

The package is a generic, with a procedure passed as a parameter to
handle events generated by X. Inside the package is a task which 
examines the X event list and calls the procedure as required.

I also have another generic package which provides a menu by 
instantiating it with an enumeration type and another procedure. This 
menu package uses the above window package to create a window and fill 
it with the elements of the enumeration type. When one of the items is 
clicked on, the procedure is called.

The problem is that if I instantiate the windows package and the menu 
package within the same executable, I end up with two tasks, each 
processing the X events. This works OK, most of the time, but sometimes 
one of the task fails during elaboration.

I have used a protected type declared externally to both packages to 
single thread the whole thing, but this still doesn't prevent the problem.

Ideally, I'd like to integrate the menu package into the window package 
so that they both use the same event loop (task) which I think will cure 
the problem.

The final problem I have is how to integrate it. If the menu package 
remains generic, it can't be called by the task. If I make it non 
generic, I can't specify an enumeration for the menu when it is created.

What I'd really like to do is to make the menu package a non generic and 
somehow pass an enumeration type to it. If not I'll have to pass a list 
of pointers to strings or something.

Sorry for the long post - any ideas welcommed.

Nige.

Re: Difficult to describe problem

[Dr. Michael Paus]

Nige wrote:
> Hi - Sorry about the ambiguous title of this post, but it's hard to sum 
> up the problem.
> 
> What I have is a simple Ada interface to the Xlib function which 
> contains functions for creating windows, and drawing in them, etc.
> 
> The package is a generic, with a procedure passed as a parameter to
> handle events generated by X. Inside the package is a task which 
> examines the X event list and calls the procedure as required.
> 
> I also have another generic package which provides a menu by 
> instantiating it with an enumeration type and another procedure. This 
> menu package uses the above window package to create a window and fill 
> it with the elements of the enumeration type. When one of the items is 
> clicked on, the procedure is called.
> 
> The problem is that if I instantiate the windows package and the menu 
> package within the same executable, I end up with two tasks, each 
> processing the X events. This works OK, most of the time, but sometimes 
> one of the task fails during elaboration.
> 
> I have used a protected type declared externally to both packages to 
> single thread the whole thing, but this still doesn't prevent the problem.
> 
> Ideally, I'd like to integrate the menu package into the window package 
> so that they both use the same event loop (task) which I think will cure 
> the problem.
> 
> The final problem I have is how to integrate it. If the menu package 
> remains generic, it can't be called by the task. If I make it non 
> generic, I can't specify an enumeration for the menu when it is created.
> 
> What I'd really like to do is to make the menu package a non generic and 
> somehow pass an enumeration type to it. If not I'll have to pass a list 
> of pointers to strings or something.
> 
> Sorry for the long post - any ideas welcommed.
> 
> Nige.
> 

In Ada95 it is possible to pass an instance of a generic package to another
generic package in order to avoid multiple instantiations. Have a look at
chapter 12.7 of the Ada95 RM. If I understood your problem description correctly
this should help you to avoid the task duplication.

Michael

Re: Difficult to describe problem

[Stephen Leake]

Nige <nigel.scott@uk.thalesgroup.com> writes:

> Hi - Sorry about the ambiguous title of this post, but it's hard to
> sum up the problem.
> 
> <snip discription of tasks and X processing>

One suggestion is to use GtkAda; it already solves this problem.

But if you are doing this to learn how it is done, here are some other
ideas.

Place the event loop task outside both generics, and pass a pointer to
it in the generic formal parameters.

Use a simple procedure for the event loop, not a task. Then the
procedure can be called at any point to get a nested event loop. That
gives you modal dialog boxes, for example.

-- 
-- Stephe

Re: Difficult to describe problem

[Ted Dennison]

Nige <nigel.scott@uk.thalesgroup.com> wrote in message news:<3D11C7BA.8040504@uk.thalesgroup.com>...
> The package is a generic, with a procedure passed as a parameter to
> handle events generated by X. Inside the package is a task which 
> examines the X event list and calls the procedure as required.
...
> The problem is that if I instantiate the windows package and the menu 
> package within the same executable, I end up with two tasks, each 
> processing the X events. This works OK, most of the time, but sometimes 
> one of the task fails during elaboration.
> 
> I have used a protected type declared externally to both packages to 
> single thread the whole thing, but this still doesn't prevent the problem.

X is not thread-safe. This may not be your current problem, but it
*will* cause you problems. If your X bindings don't synchronize
accesses to X, you will have to do it yourself. Typically the easiest
way is to just desginate one task as the X-calling task, and use
protected queues or rendezvous to pass it requests from other tasks
(you will probably need a time-out on either the accept or the X event
wait so neither gets starved).

As for your current problem, without the code its tough to guess. My
guess would be that one of your tasks is trying to use an object
(perhaps the X application context?) before some other task has the
object fully initialized. Putting a "Start_Processing" entry in your
tasks usually solves this kind of problem.

Re: Difficult to describe problem

[Simon Wright]

dennison@telepath.com (Ted Dennison) writes:

> X is not thread-safe.

Some modern X distributions do have thread support; check
XInitThreads(), XtToolkitThreadInitialize().

Of course higher libraries (Motif) might not be thread-safe (I just
don't kmow the answer here, more research needed, sorry!)

Re: Difficult to describe problem

[Nige]

Simon Wright wrote:
> dennison@telepath.com (Ted Dennison) writes:
> 
> 
>>X is not thread-safe.
> 
> 
> Some modern X distributions do have thread support; check
> XInitThreads(), XtToolkitThreadInitialize().
> 
> Of course higher libraries (Motif) might not be thread-safe (I just
> don't kmow the answer here, more research needed, sorry!)

Thanks for the replies to my original message. I've actually rewritten 
my code completely now to remove the generics and instead have a single 
event handling task, with a list of subscribed window objects. Seems to 
work OK...

Cheers,
Nige.