Version française
Home     About     Download     Resources     Contact us    
Browse thread
Threads Package for Win/NT
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David McClain <dmcclain@a...>
Subject: Threads Package for Win/NT
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