Re: Interfacing to C: multithreaded callbacks

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 13 Cze, 10:11, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
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/