Why thread.cmi of vmthreads/systhreads different

Why thread.cmi of vmthreads/systhreads different

[Zheng Li]

Hi

I found that the thread.cmi in $STDLIB/vmthreads and $STDLIB/threads are
different, while others interface files (event.cmi, condition.cmi and
mutex.cmi) are the same.

By looking at the source, I found that the slight differences coming from two
thread.mli on the following aspects:

1) a few values explicitly declared as "external" in the interfaces hence
different from each other, as the implementations vary. e.g

  +val self : unit -> t     
  -external self : unit -> t = "caml_thread_self"

  +external id : t -> int = "thread_id"   
  -external id : t -> int = "caml_thread_id"

However, by substituting "external" with "val" can obviously unify them. Is
there any special reasons, except slight efficiency difference, to keep them
external in the interface?

2) values "sleep", "wakeup" "critical_section" only exist in vmthread and
"sigmask" only exist in systhreads. However,

 - Isn't it possible to complete these slots with dummy functions on both
   sides so that they can agree? Especially, "sleep" etc. are for internal use
   only and hidden from the doc by default, besides there already exist some
   precedents like that (e.g. wait_read and wait_right of systhreads)

 - The Thread module section of OCaml manual seems to be generated from the
   systhreads interface, then how about if I call Thread.sigmask on vmthreads?

My point is that two different versions of thread.cmi greatly reduce the
flexibility. I don't see many obstacles to make them agree, but I'm not sure
whether there exist other factors to prevent that from happening. On the other
hand, if this would never happen (officially), I'm fine with wrapping a common
interface module, just a bit strange.

-- 
Zheng Li
http://www.pps.jussieu.fr/~li

Re: [Caml-list] Why thread.cmi of vmthreads/systhreads different

[Chris King]

On 7/27/07, Zheng Li <li@pps.jussieu.fr> wrote:
> My point is that two different versions of thread.cmi greatly reduce the
> flexibility. I don't see many obstacles to make them agree, but I'm not sure
> whether there exist other factors to prevent that from happening.

This is a perfect example of a situation in which Piotr Wieczorek's
interface manipulation patches [1] would come in handy.  In
particular, they would allow each of the implementations of the Thread
module to be retyped to a common interface, so that they can share a
.cmi.

- Chris

[1] http://caml.inria.fr/pub/ml-archives/caml-list/2006/12/c7461312202053f2213a9bb33206fcb8.en.html