Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Systhreads under Win/NT
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David McClain <barabh@q...>
Subject: [Caml-list] Systhreads under Win/NT

I have been trying to get a DLL running, as written in OCaml. I have been
quite successful, but along the way I had to modify the Thread.ML source to
become a delayed initialization.

Currently inside the Thread.ML source file there is a line that reads:

(* Initialization of the scheduler *)

let _ =
  ignore(Sys.signal Sys.sigterm (Sys.Signal_handle preempt));

I would suggest that this be changed to the following with a Lazy.force
applied at the beginning of Thread.create:

(* Initialization of the scheduler *)

let init =
  lazy(ignore(Sys.signal Sys.sigterm (Sys.Signal_handle preempt));

let create fn arg =
  Lazy.force init;
    (fun () -> ......

Doing this allows DLL's to call   caml_startup()  without fear of blowing
out of the water. During DllMain() the code is only permitted restricted
capabilities, and starting up new threads is apparently not one of them.

Finally, here is a question for the pro's who wrote the SysThreads C code...

I understand from reading the M$ documentation that Thread Local Store is at
least 64 words long. But not guaranteed to be any larger than this. Since
your C code uses two global vars labeled as thread local, i.e.,

/* The descriptor for the currently executing thread (thread-specific) */

static __declspec( thread ) caml_thread_t curr_thread = NULL;

[...other code elided...]

/* The thread-specific variable holding last locked I/O channel */

static __declspec( thread ) struct channel * last_channel_locked = NULL;

...doesn't this imply that there is a limit of 64 systhreads guaranteed in
the system?

Second part of question, more of a comment, is that when DLL's are created,
manual loading via LoadLibrary() obviates the use of Thread Local storage,
as per M$ documentation. That means that one cannot use LoadLibrary() to
load a threaded OCaml DLL, as the thread storage mechanism relied upon by
the systhreads is not properly activated by the loading process. I have
tried doing this anyway, but with mixed success. It appears that the storage
mechanism offered to a DLL with LoadLibrary() is not robust against this
kind of use....

I don't have a solution to this problem just yet, but I am working on one...
Any ideas?


- David McClain, Sr. Scientist, Raytheon Systems Co., Tucson, AZ
Bug reports:  FAQ:
To unsubscribe, mail  Archives: