Interfacing to C: multithreaded callbacks

Interfacing to C: multithreaded callbacks

[Maciej Sobczak]

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/

Re: Interfacing to C: multithreaded callbacks

[Dmitry A. Kazakov]

On Tue, 12 Jun 2007 12:56:30 -0700, Maciej Sobczak wrote:

> 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.

Yes, when Ada tasks aren't mapped onto system threads, then system calls
potentially might block all Ada tasks. This includes whatever POSIX layer.

> 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.

You can marshal messages from C callbacks. With busy waiting and one
publisher - one subscriber, you don't need anything but shared memory to
implement that.

However, when talking about  POSIX targets, I would assume Ada tasks being
POSIX threads.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing to C: multithreaded callbacks

[Maciej Sobczak]

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/

Re: Interfacing to C: multithreaded callbacks

[Dmitry A. Kazakov]

On Wed, 13 Jun 2007 08:23:08 -0700, Maciej Sobczak wrote:

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

At least it will give you a chance to use POSIX synchronization objects
when talking with Ada tasks.

Just take an Ada OS instead, with POSIX stuff implemented on the top of Ada
RTL. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing to C: multithreaded callbacks

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> 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.

For GNAT, see GNAT.Threads.Register/Unregister_Thread -- they seem to
think it's quite tricky, maybe other vendors have a different slant.