From: "David McClain" <dmcclain@azstarnet.com>
To: <caml-list@inria.fr>
Subject: Threads Library
Date: Wed, 29 Dec 1999 02:41:49 -0700
I just received a copy of Reppy's new book on "Concurrent ML". I was
delighted to find that the OCAML Threads library incorporates much of his
work with channels and events.
However, unlike CML, (on Windows/NT at least) the GC does not discard
threads hung up on channels that are no longer in use by active threads.
Hence the use of speculative spawning is not safe in WinNT/OCAML. (Early
experiments generated thousands of threads before I had to kill off the
program).
Secondly, it would appear that the semantics of "with_abort" require that
the wrapper function be called ahead of all "with" functions. But
experiments where a with-function raises an exception bypass the actions of
pending "with_abort" functions on non-selected channels. So evidently, one
should not permit the use of uncaught exceptions inside of "with" functions.
Finally, where Reppy's CML uses continuations to effect tail calls, I wonder
about the use of indefinite recursion triggered by a with-function. It would
seem that one should treat composite event lists in much the same manner as
"try-with" when it comes to recursion inside a try (resp. with) clause.
Instead of tail calling from the "with" clause one should return a value to
the outer level of the "sync" or "select", and then "match" on that value
before recursing.
I have implemented a module that provides thread safety, as long as the
above protocols are followed. In effect all events generated by Event.send
and Event.receive are first wrapped in a "with_abort" where the function
spawns a thread to respond to the eventual conjugate operation on the
channel. There are unsafe versions that simply repeat Event.send and
Event.receive for use when it is known that the corresponding thread will
not be ignored forever.
Do I understand the OCAML situation properly?
TIA
David McClain,
Sr. Scientist
Raytheon Systems Co.
Tucson, AZ
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:30 MET