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 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!n15g2000prd.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Interfacing to C: multithreaded callbacks Date: Wed, 13 Jun 2007 08:23:08 -0700 Organization: http://groups.google.com Message-ID: <1181748188.465208.3770@n15g2000prd.googlegroups.com> References: <1181678190.757347.67290@x35g2000prf.googlegroups.com> NNTP-Posting-Host: 137.138.37.241 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1181748189 7637 127.0.0.1 (13 Jun 2007 15:23:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 13 Jun 2007 15:23:09 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070601 Red Hat/1.5.0.12-0.1.slc3 Firefox/1.5.0.12,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: n15g2000prd.googlegroups.com; posting-host=137.138.37.241; posting-account=Ch8E9Q0AAAA7lJxCsphg7hBNIsMsP4AE Xref: g2news1.google.com comp.lang.ada:16179 Date: 2007-06-13T08:23:08-07:00 List-Id: On 13 Cze, 10:11, "Dmitry A. Kazakov" wrote: > You can marshal messages from C callbacks. Yes, that might be some possibility. Going further in this direction, I might even isolate the C library in a separate process and communicate with it from Ada client using some appropriate IPC. I can imagine scenarios where that makes sense. > However, when talking about POSIX targets, I would assume Ada tasks being > POSIX threads. Yes, that should be obvious implementation strategy. It doesn't automagically solve all problems, though. The threads started by C library will be "pure virgin threads", without any Ada-related context information that might be stored in TLS (Thread Local Storage), for example. Crossing the border between C and Ada in a callback is a matter of calling convention and single pragma, but depending on what the Ada subprogram tries to do next it might work or not. Just imagine that such a subprogram will try to do some tasking-related stuff (rendezvous with other Ada task? etc.) and from the point of view of Ada runtime will be just a foreigner. I think that C threads should not pretend to be Ada tasks, unless we know *everything* about the particular Ada implementation. Some GNAT developers might shed some light here. Fortunately, the C library I have in mind offers (possibly blocking) polling as alternative to callbacks, so that it should be possible to set up "normal" Ada task that will poll the library for state changes and then do regular Ada callbacks to other subprograms when needed. This way C threads will not mess around Ada runtime. But I can imagine C libraries that don't provide this opportunity; then marshaling or total isolation might be the correct solution. -- Maciej Sobczak http://www.msobczak.com/