Interfacing to C: multithreaded callbacks

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

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/