[MLton] threads in mlton

Stephen Weeks MLton@mlton.org
Thu, 27 Apr 2006 17:24:53 -0700


> Ocaml is single threaded and I can't accept this limitation because
> multiple threads refer to the same data in my multithreaded program,
> and I need the leverage of the additional CPUs.

MLton doesn't support simultaneous access to multiple CPUs within a
single program.

> I understand threads in mlton are implemented on top of native
> threads.

This is incorrect.  MLton implements its own threads, and all run
within a single native thread.

Please see:

  http://mlton.org/MLtonThread

> I want some thread, say thr1 to be able to interrupt or possibly
> cancel a descendant thread thr12 reliably and quickly

There is no support for this in MLton.Thread.  However, you might be
able to build it in to a higher-level threads package.  Also, you
might want to look into Concurrent ML (CML), which MLton supports.

  http://mlton.org/ConcurrentML

I'm not sure if this is related, but there are a couple of papers
linked from

  http://mlton.org/ConcurrentMLImplementation

that explain why arbitarily killing a thread is a bad idea.

  http://mlton.org/References#MarlowEtAl01
  http://mlton.org/References#FlattFindler04

> Let's say thr12 is blocked in a system call such as read(), I'll be
> quite satisfied if the interruption request from thr1 somehow
> manages to unblock thr12 and causes it to throw an exception.

You could easily do something like this in CML with selective
communication.  Have thr12 do a choose between the system read and a
channel read, and have thr1 send a message on the channel to indicate
an abort.

> If the mlton program is linked to C code via the FFI, then are there
> any constraints/precautions that need to be observed during
> interruptions to ensure that the program remains correct?

Not that I can think of.  Interruptions in blocked C calls are
represented by returning error codes.  MLton's system calls are
wrapped at the lowest level by SML code that turns C error conditions
into SML exceptions.