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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b4185948f9f2555 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-12-27 17:24:48 PST Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!news1.digex.net!ois.com!ois.com!not-for-mail From: beckwb@ois.com (R. William Beckwith) Newsgroups: comp.lang.ada Subject: Re: Ada and shared memory question Date: 27 Dec 1994 12:14:09 -0500 Organization: Objective Interface Systems, Inc. Message-ID: <3dpi11$c67@gamma.ois.com> References: NNTP-Posting-Host: gamma.ois.com X-Newsreader: TIN [version 1.2 PL2] Date: 1994-12-27T12:14:09-05:00 List-Id: Chris Warwick (cwarwick@fox.nstn.ns.ca) wrote: : I have had very little luck getting system specific info, but the compiler is : Verdix, and the OS is SCO UNIX... : Does anyone know how the Ada RTE usually implemented on non-threaded UNIX : systems? A non-threaded Unix gives each process only one thread. There are some Ada compiler's (OC Systems) that can map each Ada task to a separate process, but this is not the common implementation. Most Ada tasking kernels divvy up the one thread to multiple Ada tasks. The Ada tasking kernels (usually) do the context switches among the Ada tasks by using setjmp/longjmp to change stacks. This is similiar to the implementation methods used by other threading environments (DCE) when on non-threaded O/S's. In addition, the Ada RTE's usually support timeslicing by scheduling SIGALARM's frequently to allow for a context switch. There are three hurdles you face when using C code (SQL, O/S, GUI, et al) that was not built to support multiple threads with Ada tasks in this kind of Ada RTE implementation: 1. blocking - usually the C code calls select or a blocking I/O operation that will cause the Unix kernel to stop timeslicing or block all of the tasks in that process 2. non-reentrant C code - most C code was not written with threads in mind and thus has many global states (variables) that can get out of sync with multiple threads 3. no object protection - you can't update the same C object from multiple Ada tasks since there is no semaphore in the C code to coordinate access A good binding written by someone with access to the C source should address most or all of these issues. : Is it linked into each executable, or is some sort of shared library : used? Every Ada compiler I've seen statically links the RTE into the executable. : We are trying to write an Oracle SQL procedure to call services provided by : our Ada programs. The problem seems to be the Ada RTE code is not being : correctly linked or referenced. One solution I thought of would be to place : the code into a shared memory buffer, and provide a C front end to access the : memory and call the service. Is this a reasonable use of shared memory? Can : I do this in Ada? Has anyone out there tried this? Are you trying to use tasking with the Oracle client? Or is the full extent of the problem a link error? I have heard of others having problems linking with Oracle, but I don't know the details. ... Bill