RE: [Caml-list] Systhreads under Win/NT

RE: [Caml-list] Systhreads under Win/NT

[Dave Berry]

> From: Xavier Leroy [mailto:xavier.leroy@inria.fr]
> Sent: 30 November 2001 10:20
> 
> > 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, [...]
> > ...doesn't this imply that there is a limit of 64 
> > systhreads guaranteed in the system?
> 
> I understand this limitation as "at most 64 words of TLS *per 
> thread*".

There is definitely one system wide limit of 64 thread words in NT,
and I think this is it.  In Windows 2000 this was increased to 1088
(i.e. 64 + 1024).  And yes, if your threads store local values, this
does limit the number of threads you can use.  One of our customers
ran into this, and it was very difficult to track down.  MS don't
exactly hide this limit, but it's far from obvious.

Dave.

-------------------
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

Re: [Caml-list] Systhreads under Win/NT

[Xavier Leroy]

> 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.
> 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.

OK, I wasn't aware of this restriction.  A simple workaround is to
remove the creation of the "tick" thread (the one that generates
context-switch events at regular intervals) from caml_startup(),
and create it when the first user thread is created.  There is no need
to generate context-switches until at least two threads are running!
I'll see what I can do about it.

> --------------------------
> 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?

I understand this limitation as "at most 64 words of TLS *per thread*".
Since we're using only 2, that should be OK, without limiting the
number of threads created.

> 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.

Correct.  In the working sources, in order to support dynamic loading
of the Systhread C code, I rewrote the __declspec(thread) variables
into explicit calls to TlsGetValue and TlsSetValue, to work around
this issue.

- Xavier Leroy
-------------------
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

[Caml-list] Systhreads under Win/NT

[David McClain]

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