What are the conditions of using Unix and Thread modules with ocamljava?

[struktured]

I was trying to determine how Unix and Thread are implemented. Do these modules still depend on C libraries or are they pure Java? I noticed, for instance, that some functions are not supported:

Unix.getpid();; Exception: Invalid_argument "Unix.getpid not implemented".

Is this a natural consequence of tunneling all Unix calls through the JVM (that is, java doesn't strongly support a notion of a process ID)? Is the Thread module similarly implemented?

[xclerc]

As you guessed, the JVM provides only limited support for POSIX operations. For the time being, implementation of primitives is basically best effort; however, in the future, JNA (https://github.com/twall/jna) may be used to leverage native libraries (if present, with a fallback to the current implementation).

As you noticed, support for "unix" and "threads" libraries is only partial ; I have just set up a web page (currently not linked to the rest of the website) with the compatibility information: http://www.ocamljava.org/more/compatibility.html

Finally, note that the "threads" library has been only lightly tested and I would recommend to use it iff your code is also targeting ocamlc/ocamlopt. Indeed, the "concurrent" (http://www.ocamljava.org/files/api/concurrent/index.html) library (which is ocamljava-specific) has a lower overhead, is largely more tested, and can leverage multiple cores...

[struktured]

That answers my questions-I was only considering using threads so that I could compile some existing ocaml modules into cmj format. Lots of useful libraries depend on lwt, which requires the unix and threads modules.

You can close this if you wish, unless you want to leave it open until it's properly documented on the website.

[xclerc]

I will keep the issue open until the information is really available (page referenced from the website, manual, etc.).

Incidentally, I wonder whether it would make sense to have a custom lwt backend for OCaml-Java. To be sure not to rely on a (partially) incompatible primitive, or on existence of a global lock.

[struktured]

I was thinking along similar lines regarding the lwt backend. The same argument can be made for Jane Street's async package as well.