[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.