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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5d05ccde5cefb836 X-Google-Attributes: gid103376,public From: dennison@telepath.com Subject: Re: Tasks and C/C++ code. Date: 1998/11/11 Message-ID: <72coif$653$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 410793749 References: <364702E5.F6987321@hiwaay.net> <729ndu$jfo$1@nnrp1.dejanews.com> <72b35b$pll$1@nnrp1.dejanews.com> X-Http-Proxy: 1.0 x13.dejanews.com:80 (Squid/1.1.22) for client 204.48.27.130 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Nov 11 19:29:19 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.05 [en] (WinNT; I) Date: 1998-11-11T00:00:00+00:00 List-Id: In article <72b35b$pll$1@nnrp1.dejanews.com>, dbotton@hotmail.com wrote: > I think it would be practical to create a protected type that wrapped your C > function to insure that it is not be run concurrently (if it isn't safe). If > it's safe then just call it as you would any other Ada Procedure/Function. That will only work under both of the following conditions: o There is only *one* object of that protected type in use. If there are multiple objects of the protected type declared, then there's nothing stopping two tasks from using different protected objects to call the same routine simultaniously. o The C routine in question does not rely on task-local data for proper operation or for parameter data. In Ada we are used to data being either local in *scope*, or visible to all tasks. But this is not nessecarily true when we leave Ada's happy confines. eg: The Nighthawk Ada compiler splits tasks into separate Unix processes. All Ada memory allocations are performed from shared memory sections. However, their C compiler and OS library routines allocate memory from process space. That means any data that was dynamicly allocated by a different task within a C routine or OS library routine is unreadable from any but the calling task. Thus calling X or Motif routines directly from different tasks will blow up, regarless of how the calls are synchronized. Many of the newer threaded OS'es have the concept of "thread-local" data. That could cause the same problem. -- T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own