> 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