C-threads & callbacks

C-threads & callbacks

[Markus Mottl]

Hi,

I'm currently interfacing a 3rd-party library that spawns threads
to execute callbacks.  I would like those callbacks to be handled by
OCaml-code, but have run into some issues here.

As it seems, it is not possible to run OCaml-code linked with thread
support while letting C-threads perform callbacks.  This has already
been a topic on the list a while ago.

I have two solutions in mind: the first one would involve pre-spawning
an OCaml-thread and pass data from C to OCaml through an OCaml-reference
exposed to C, protected by mutexes and condition variables.  This seems
pretty ugly, because it's error-prone and also involves a considerable
amount of context-switching, which is bad for my application (very high
volume realtime data).

The second solution would require setting up an OCaml thread descriptor
for the currently executing C-thread.  However, AFAIK this solution
cannot be implemented without fiddling with the implementation of the
OCaml-runtime, because some global variables for thread-handling are not
exposed to user code (i.e. "static").  It would be great if the thread
implementation offered functions allowing users to have their C-threads
"migrate" to OCaml.

Does anybody know of another elegant and efficient solution for this
problem that does not require hacking the OCaml-runtime?

Best regards,
Markus

Re: [Caml-list] C-threads & callbacks

[Daniel Bünzli]

> As it seems, it is not possible to run OCaml-code linked with thread
> support while letting C-threads perform callbacks.  This has already
> been a topic on the list a while ago.

I don't understand what you are refering to. I don't think there's a 
problem as long as you take care to acquire ocaml's global lock to 
exectue the callbacks.

#include <caml/signals.h>
...
caml_leave_blocking_section();
callback(*caml_named_value("myfun"), Val_unit);
caml_enter_blocking_section();
...

This ensures that callbacks into caml are properly serialized.

Daniel

Re: [Caml-list] C-threads & callbacks

[Markus Mottl]

Daniel Bünzli schrieb am Donnerstag, den 20. Jänner 2005:
> I don't understand what you are refering to. I don't think there's a 
> problem as long as you take care to acquire ocaml's global lock to 
> exectue the callbacks.
> 
> #include <caml/signals.h>
> ...
> caml_leave_blocking_section();
> callback(*caml_named_value("myfun"), Val_unit);
> caml_enter_blocking_section();
> ...
> 
> This ensures that callbacks into caml are properly serialized.

This only works if the callback is performed by a thread that was
spawned by OCaml (i.e. OCaml -> C -> OCaml).  In this case the runtime
knows what the "current thread" is.  But if a C-thread executes
"caml_leave_blocking_section" (C -> OCaml), it can segfault there,
because there may be no "current thread".  And if there is, it is not
the C-thread but another currently executing OCaml-thread, which will
mess things up later.

That's why there should be some way to register a C-thread with the
OCaml-runtime.  Currently this does not seem to be possible without
hacking the OCaml-implementation.

Regards,
Markus

--
Markus Mottl    markus.mottl@gmail.com    http://www.ocaml.info

Re: [Caml-list] C-threads & callbacks

[Alex Baretta]

Markus Mottl wrote:
> Hi,
> 
> I'm currently interfacing a 3rd-party library that spawns threads
> to execute callbacks.  I would like those callbacks to be handled by
> OCaml-code, but have run into some issues here.
> 

Just a thought: how about running two different processes which share 
relevant data through an mmapped file? The C-threads could communicate 
with the Ocaml world through this shared memory segment. I am not sure 
how much mileage you'll get out of this, but at least you would not have 
to rewrite the runtime system...

Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

Re: [Caml-list] C-threads & callbacks

[Markus Mottl]

On Thu, 20 Jan 2005, Alex Baretta wrote:
> Just a thought: how about running two different processes which share 
> relevant data through an mmapped file? The C-threads could communicate 
> with the Ocaml world through this shared memory segment. I am not sure 
> how much mileage you'll get out of this, but at least you would not have 
> to rewrite the runtime system...

We have also thought about this.  It would surely be a working solution
and much faster than our current cruel hack of reading data from the
tail of a file.  But a solution involving only one process would be
preferable in the long run.

Regards,
Markus

-- 
Markus Mottl    markus.mottl@gmail.com    http://www.ocaml.info

Re: [Caml-list] C-threads & callbacks

[SooHyoung Oh]

I'v resolved the same problem using TCP/IP communication between
Ocaml thread and C thread.

Markus Mottl 쓴 글:

>Hi,
>
>I'm currently interfacing a 3rd-party library that spawns threads
>to execute callbacks.  I would like those callbacks to be handled by
>OCaml-code, but have run into some issues here.
>
>As it seems, it is not possible to run OCaml-code linked with thread
>support while letting C-threads perform callbacks.  This has already
>been a topic on the list a while ago.
>
>I have two solutions in mind: the first one would involve pre-spawning
>an OCaml-thread and pass data from C to OCaml through an OCaml-reference
>exposed to C, protected by mutexes and condition variables.  This seems
>pretty ugly, because it's error-prone and also involves a considerable
>amount of context-switching, which is bad for my application (very high
>volume realtime data).
>
>The second solution would require setting up an OCaml thread descriptor
>for the currently executing C-thread.  However, AFAIK this solution
>cannot be implemented without fiddling with the implementation of the
>OCaml-runtime, because some global variables for thread-handling are not
>exposed to user code (i.e. "static").  It would be great if the thread
>implementation offered functions allowing users to have their C-threads
>"migrate" to OCaml.
>
>Does anybody know of another elegant and efficient solution for this
>problem that does not require hacking the OCaml-runtime?
>
>Best regards,
>Markus
>
>_______________________________________________
>Caml-list mailing list. Subscription management:
>http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>Archives: http://caml.inria.fr
>Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>  
>

Re: [Caml-list] C-threads & callbacks

[Alex Baretta]

SooHyoung Oh wrote:
> I'v resolved the same problem using TCP/IP communication between
> Ocaml thread and C thread.
> 

I have a feeling Markus' comment regarding "real-time" use of his 
application discourages use of TCP/IP sockets; albeit, maybe, Unix 
sockets might be fast enough and a fairly robust mechanism.

What exactly are you doing, Markus? I'm interested because we, too, here 
at DE&IT, use Ocaml for realtime applications.

Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

Re: C-threads & callbacks

[Markus Mottl]

Hi,

thanks for all the replies.  I have just implemented a solution, which
seems to be very satisfactory for our purposes.

On Fri, 21 Jan 2005, SooHyoung Oh wrote:
> I'v resolved the same problem using TCP/IP communication between Ocaml
> thread and C thread.

This would unfortunately have been way too much overhead.

On Fri, 21 Jan 2005, Alex Baretta wrote:
> What exactly are you doing, Markus? I'm interested because we, too, here 
> at DE&IT, use Ocaml for realtime applications.

We are logging financial realtime data (trades) with enormously high
data volume (tens of thousands of ticks/trades per second at peak times).

On Fri, 21 Jan 2005, Olivier Andrieu wrote:
> What about using a pipe ? the C callback stuffs its data in the pipe
> (perhaps converted to marshalled caml values) and on the other end,
> the caml callback is waiting with a blocking read.

This would still require marshalling overhead.

My solution now looks as follows:

I prespawn an OCaml-thread, which immediately goes into C-land.
There it waits on a condition variable (within a blocking section to
let other OCaml-threads run) until some C-thread makes data available
and notifies it.  Then the OCaml-thread converts the available data to
OCaml-values and performs the callback.  In the meanwhile the C-thread
blocks on a condition variable until the result is available.  Once the
OCaml-thread returns, it notifies the C-thread and waits for more data
again.  The C-thread continues as desired (terminates or does something
else, etc.).

The only overhead is context switching, everything else is negligible.

It would still be nice if there were an easy way to let C-threads safely
migrate to OCaml-land without all this thread-coordination...

Regards,
Markus

-- 
Markus Mottl    markus.mottl@gmail.com    http://www.ocaml.info

Re: [Caml-list] C-threads & callbacks

[Xavier Leroy]

> I'm currently interfacing a 3rd-party library that spawns threads
> to execute callbacks.  I would like those callbacks to be handled by
> OCaml-code, but have run into some issues here.
> 
> As it seems, it is not possible to run OCaml-code linked with thread
> support while letting C-threads perform callbacks.  This has already
> been a topic on the list a while ago.

Correct.  This is still on my "to do" list.  It sounds feasible but
requires some intervention in the runtime system and the threading
library, so it's not something that can be done on the side by
3rd-party code.

- Xavier Leroy