Julia embedding in a dylib

General Usage
,
1

I’m testing a specific case of Embedding Julia · The Julia Language on MacOS.
I need to call Julia from a dylib (dylib code in C++) that is called from Julia to pass input data and analyze the results.

In other words:

  1. from Julia prompt (or script) call mydylib.dylib using Libdl
  2. and mydylib.dylib calls internally julia code as described in the documentation (example from the documentation below, in my case the body will go inside a function in a dylib instead of a main).
#include <julia.h>
JULIA_DEFINE_FAST_TLS() // only define this once, in an executable (not in a shared library) if you want fast code.

int main(int argc, char *argv[])
{
    /* required: setup the Julia context */
    jl_init();

    /* run Julia commands */
    jl_eval_string("print(sqrt(2.0))");

    /* strongly recommended: notify Julia that the
         program is about to terminate. this allows
         Julia time to cleanup pending write requests
         and run all finalizers
    */
    jl_atexit_hook(0);
    return 0;
}

I can ignore JULIA_DEFINE_FAST_TLS() since it’s the empty macro for MacOS (not tried on Linux yet, the comment there is a bit worrisome).

In any case it mostly works, with one exception, I need to remove jl_atexit_hook(0); otherwise it will kill the Julia prompt, i.e. the main caller (the Julia prompt dies).

Is this expected? Is there anything else one should be worried about?

The use case is to replace a block of a C++ pipeline that lives in a dynamic library (dylib) with a prototype algorithm in Julia, and control the dylib from Julia (EDIT: or control the dylib from another language or executable).

PS
How do I control how many threads will the julia prototype alg called from inside my C++ dylib be using?

1 Like
2

If I understand your use case correctly you’re making things way too hard for yourself. With Julia in the driver seat you already have a running Julia and there’s no reason for the C++ code to start one itself. Just ccall into your dynamic library and pass an @cfunction pointer which your C++ code can call back into Julia with.

3

@GunnarFarneback that’s an interesting option to consider, thank you. I believe it’s discussed here: Calling C and Fortran Code · The Julia Language if I understand your suggestion.

The reason why my “approach” could be advantageous sometimes is that I might want to call the dylib not only from julia but also from other executables/scripting languages. So it would be nice to have only one version of the dylib and not to have to recompile it depending on the main caller (or have to maintain multiple versions).

4

I guess another option to call julia code from a C++ pipeline is Libraries · PackageCompiler.

1 Like