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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,94e5dd5646e21259,start X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!x35g2000prf.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Interfacing to C: multithreaded callbacks Date: Tue, 12 Jun 2007 12:56:30 -0700 Organization: http://groups.google.com Message-ID: <1181678190.757347.67290@x35g2000prf.googlegroups.com> NNTP-Posting-Host: 85.3.208.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1181678191 7596 127.0.0.1 (12 Jun 2007 19:56:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 12 Jun 2007 19:56:31 +0000 (UTC) User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: x35g2000prf.googlegroups.com; posting-host=85.3.208.3; posting-account=Ch8E9Q0AAAA7lJxCsphg7hBNIsMsP4AE Xref: g2news1.google.com comp.lang.ada:16170 Date: 2007-06-12T12:56:30-07:00 List-Id: I have identified three problems with interfacing to C, I will describe them in separate posts. Suppose there is a C library that creates additional threads (system- level threads in the pthread_create sense) and can call the client code back via function pointers that the client code provides to the library. Asynchronous I/O library that notifies the client about state changes can be a good motivating example. It is possible to pass Ada callback to the C library - it's enough to pragma Export(C, My_Procedure) and pass appropriate access to procedure. This way we could, for example, use the standard C function qsort. The problem is when the C library creates additional threads and calls the client back in the context of those threads. ARM says nothing (?) about the relaion between Ada tasks and system threads. If the relation is 1:1 (ie. tasks are implemented as system threads), then the whole scheme might work just fine, provided that there is no task- specific data that Ada runtime expects and will not find. On the other hand, if the relation between tasks and threads is not 1:1, we will just enjoy undefined behavior. Looks like a shaky ground. Is there any water-proof implementation pattern for such problems? Consider both the general case and then GNAT as the target Ada compiler on POSIX systems. -- Maciej Sobczak http://www.msobczak.com/