Well, I see now that it takes more than just one Lazy.force on the proposed
lazy init clause. In fact, any of the Thread routines that can accept a
non-Thread.t argument potentially needs the same Lazy.force inserted.

...but still, this isn't too bad...

Alas, any program statements that call upon these Thread routines at the top
level, e.g., non-closures with Thread calls for value, need to be delayed as
well, so that the DLL can successfully start up without spawning new
threads -- a no, no, in DllMain.

Of course the other possibility is to avoid calling caml_startup()
altogether from inside of DllMain, and instead handle deferred
initialization in other DLL entry points. That avoids the problem entirely,
but forces less automatic behavior on the user of the DLL.

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