Well I ran into another problem here with a threaded DLL backend for a
COM/OLE server. Since the incoming DLL requests are happening on arbitrary
threads that have never been seen by the OCaml code (OCaml did not start
them), these foreign threads are beyond the machinery of the OCaml threading
engine. There are no control blocks established for them.

Secondly, with a well controlled environment and only one thread making
requests = the starter thread, I find that the use of the Reppy protocol in
Event becomes unreliable when many small slave threads are spawned. Perhaps
the system thread mechanism is too heavy handed for this approach. Reppy got
by in CML with discarding the stack, using the heap for a spaghetti stack,
and making lightweight objects under his sole control for threading. He also
has GC incorporate thread scavenging.

My fear is that M$ system threads are just too clunky for Reppy-style
threading in Event.ml.  I already realize that we can't fully implement
Reppy's speculative threading, since the GC can't scavenge useless
threads -- i.e., not yet dead, but will never be awekened for running.

So anyway, I welcome any thoughts by the group...

- 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