Re: [Caml-list] Thread-private data in C stubs

Re: [Caml-list] Thread-private data in C stubs

[jonathan]

On Monday, 27 August 2012 22:08:18 UTC+1, Andre Nathan  wrote:
> On Mon, 2012-08-27 at 16:41 -0300, Andre Nathan wrote:
> 
> > Hello
> 
> > 
> 
> > I'm writing stubs to a C library uses pthreads and exposes two functions
> 
> > to get and set thread-private data, getpriv(ctx) and setpriv(ctx, p)
> 
> > where ctx is some opaque context object, and p is a void* pointer.
> 
> > 
> 
> > What's the best way to deal with this from the stub code, ie., how do I
> 
> > avoid the thread-private data to be garbage collected when the OCaml
> 
> > variable goes out of scope?
> 
> > 
> 
> > Since the library in question uses threads internally, this needs to be
> 
> > a thread-safe solution.
> 
> 
> 
> For the record, with help from #ocaml, I got it to work like this:
> 
> 
> 
> struct priv {
> 
>   value v;
> 
> };
> 
> 
> 
> CAMLprim value
> 
> caml_setpriv(value ctx_val, value priv_val)
> 
> {
> 
>     CAMLparam2(ctx_val, priv_val);
> 
>     context *ctx = (context *)ctx_val;
> 
>     struct priv *p;
> 
>    
> 
>     p = getpriv(ctx);
> 
>     if (p != NULL) {
> 
>         caml_remove_global_root(&(p->v));
> 
>         caml_stat_free(p);
> 
>     }
> 
> 
> 
>     p = caml_stat_alloc(sizeof(*p));
> 
>     p->v = priv_val;
> 
>     ret = setpriv(ctx, p);
> 
>     caml_register_global_root(&(p->v));
> 
> 
> 
>     CAMLreturn(Val_unit);
> 
> }
> 
> 
> 
> 
> 
> -- 
> 
> Caml-list mailing list.  Subscription management and archives:
> 
> https://sympa-roc.inria.fr/wws/info/caml-list
> 
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> 
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Dear Andre, in my view it is needlessly inefficient to create a new global root for every item which crosses the C-interface. I used a system which uses dlmalloc to carve up an allocated caml custom block into convenient sized chunks. Each of these large blocks could be a local root or they could be chained together from one global root. Another advantage is that subroutines written in C that allocate memory do not need to know they are running under caml if dlmalloc is compiled to replace the system malloc. The one downside is that it is difficult to track when the global blocks are ready to be released. My impression is ocaml runtime would get very slow if there were huge numbers of global roots.

Re: [Caml-list] Thread-private data in C stubs

[Andre Nathan]

On Mon, 2012-08-27 at 16:41 -0300, Andre Nathan wrote:
> Hello
> 
> I'm writing stubs to a C library uses pthreads and exposes two functions
> to get and set thread-private data, getpriv(ctx) and setpriv(ctx, p)
> where ctx is some opaque context object, and p is a void* pointer.
> 
> What's the best way to deal with this from the stub code, ie., how do I
> avoid the thread-private data to be garbage collected when the OCaml
> variable goes out of scope?
> 
> Since the library in question uses threads internally, this needs to be
> a thread-safe solution.

For the record, with help from #ocaml, I got it to work like this:

struct priv {
  value v;
};

CAMLprim value
caml_setpriv(value ctx_val, value priv_val)
{
    CAMLparam2(ctx_val, priv_val);
    context *ctx = (context *)ctx_val;
    struct priv *p;
   
    p = getpriv(ctx);
    if (p != NULL) {
        caml_remove_global_root(&(p->v));
        caml_stat_free(p);
    }

    p = caml_stat_alloc(sizeof(*p));
    p->v = priv_val;
    ret = setpriv(ctx, p);
    caml_register_global_root(&(p->v));

    CAMLreturn(Val_unit);
}

[Caml-list] Thread-private data in C stubs

[Andre Nathan]

Hello

I'm writing stubs to a C library uses pthreads and exposes two functions
to get and set thread-private data, getpriv(ctx) and setpriv(ctx, p)
where ctx is some opaque context object, and p is a void* pointer.

What's the best way to deal with this from the stub code, ie., how do I
avoid the thread-private data to be garbage collected when the OCaml
variable goes out of scope?

Since the library in question uses threads internally, this needs to be
a thread-safe solution.

Thanks in advance,
Andre