From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,629fb94ebc84f06a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-21 08:09:01 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dennison@telepath.com (Ted Dennison) Newsgroups: comp.lang.ada Subject: Re: Difficult to describe problem Date: 21 Jun 2002 08:09:01 -0700 Organization: http://groups.google.com/ Message-ID: <4519e058.0206210709.69b73666@posting.google.com> References: <3D11C7BA.8040504@uk.thalesgroup.com> NNTP-Posting-Host: 65.115.221.98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1024672141 27001 127.0.0.1 (21 Jun 2002 15:09:01 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 21 Jun 2002 15:09:01 GMT Xref: archiver1.google.com comp.lang.ada:26560 Date: 2002-06-21T15:09:01+00:00 List-Id: Nige 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.