[Caml-list] Systhreads under Win/NT

["David McClain" <barabh@qwest.net>]

Hi,

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));
  thread_initialize()


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));
       thread_initialize())

let create fn arg =
  Lazy.force init;
  thread_new
    (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?

Cheers!

- David McClain, Sr. Scientist, Raytheon Systems Co., Tucson, AZ
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr