Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "David McClain" <dmcclain@azstarnet.com>
To: <caml-list@inria.fr>
Subject: Threads Package for Win/NT
Date: Tue, 13 Jun 2000 13:47:10 -0700	[thread overview]
Message-ID: <000701bfd578$8d97f080$250148bf@vega> (raw)

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






                 reply	other threads:[~2000-06-13 21:14 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000701bfd578$8d97f080$250148bf@vega' \
    --to=dmcclain@azstarnet.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox