Threads Package for Win/NT

From: David McClain (dmcclain@azstarnet.com)
Date: Tue Jun 13 2000 - 22:47:10 MET DST

  • Next message: Sven LUTHER: "Re: Newsgroup for Caml?"

    Hi all!

    In case anyone is interested, I have slightly modified the threads package
    on Win/NT to make event channels behave somewhat more closely to the
    Channels described by John Reppy in his new book on Concurrent ML. We have
    everything that CML has, except that we can't use speculative threading to
    any great extent. I don't know how to make the GC collect suspended
    threads... But other than that the behavior is now very close to Reppy's
    description.

    Changes were mostly very minor to Condition.ml, Mutex.ml, and Thread.ml. The
    C source Win32.c had to be slightly altered to accommodate cleanup of
    permanently suspended threads, and to add some safety checking on waiting
    for condition vars and mutexes that get discarded. The major changes
    occurred in Event.ml where Reppy-style channel handling was extended for
    sync() and poll() operations. New routines were also added:

    Thread.init : unit -> unit
    Mutex.discard : Mutex.t -> unit
    Condition.discard : Condition.t -> unit
    Event.discard_channel : 'a Event.channel -> unit

    Event.with_nack : (unit Event.event -> 'a Event.event) -> 'a Event.event
            (* [with_nack fn] returns the event that, when synchronized,
        computes [fn nackEvt] and behaves as the resulting event.
        [fn nackEvt] should compute an event as in [guard fn] that
        can serve as a synchronization point.
        [nackEvt] will be a unit event that represents the event
        signaled when the event computed by [fn nackEvt] is *NOT*
        chosen. *)

    You can get the slightly modified sources at:
    http://www.azstarnet.com/~dmcclain/threads.zip (18K compressed)

    Also, since startup of the threads package interferes with COM/OLE
    registration, I have invented a Thread.init : unit -> unit. Hence in order
    to launch the use of threads one must explicitly call Thread.init().
    Automatic startup, although desirable, conflicts with the automatic
    registration process for Windows COM DLL's. If this is no concern to you, it
    is easy to change the startup behavior in Threads.ml.

    Cheers,

    David McClain



    This archive was generated by hypermail 2b29 : Tue Jun 13 2000 - 23:16:29 MET DST