caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: caml-list <caml-list@inria.fr>
Subject: Question about ocaml threads and TLS (on linux)
Date: Wed, 24 Feb 2010 22:00:12 +0100	[thread overview]
Message-ID: <87ocje2vtv.fsf@frosties.localdomain> (raw)

Hi,

I'm having a little problem for my libfuse-ocaml bindings for the
threaded interface. For those that don't want to read all of the mail my
question is:

Will every ocaml thread have its own thread-local-storage in the C stubs?


I have the following calling sequence:

User ocaml code   | Fuse C stub              | libfuse code
------------------+--------------------------+-------------
Fuse.process fs   > 'process stub'           |
                  | enter_blocking_section() |
                  | char *buf = malloc(size) |
                  | fuse_session_process()   >
                  |                          < ops->write(buf+off)
                  | 'write stub'             |
                  | leave_blocking_section() |
                  | a = caml_ba_alloc_dims() |
                  < caml_callback(...,a,...) |
my_ref := a       >                          |
                  | enter_blocking_section() >
                  |                          < callback done
                  | 'process stub'           |
                  | free(buf)                |
                  < leave_blocking_section() |
Fuse.process done |


The 'process stub' allocates a buffer and frees it at the end, which is
usualy fine. Except in the case of a write callback where the buffer is
passed back to ocaml as Bigarray. If the Bigarray is copied, like above,
then the ocaml code still has a reference to the data at the point the
'process stub' wants to free it.

To solve that problem I need the write callback to signal that the
buffer was passed to ocaml and is now under GC control. The buffer must
not be free()ed by the 'process stub'. The libfuse API does not provide
for this so I have to somehow communicate between 'process stub' and
'write stub' around the libfuse code.


Possible solution:
------------------

__thread char *buf = NULL;

value ocaml_fuse_process(...) {
  buf = malloc(size);
  fuse_session_process()
  if (buf != NULL) free(buf);
}

void write_callback(...) {
  a = caml_ba_alloc_dims(...);
  buf = NULL;
}


This way ocaml_fuse_process will allocate a new buffer whenever it
doesn't have one and the write_callback will take over the buffer and
give it to the GC.


Now my question is: Does that work? Is it safe? Will every ocaml thread
have its own thread-local-storage buf?

Currently I'm only interested in supporting Linux. If it is safe there
that is enough.

MfG
        Goswin


             reply	other threads:[~2010-02-24 21:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-24 21:00 Goswin von Brederlow [this message]
2010-02-24 21:22 ` [Caml-list] " Philippe Wang
2010-02-25  7:25   ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ocje2vtv.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).