[MLton-user] simple, portable, asynchronous programming in SML

Matthew Fluet fluet@cs.cornell.edu
Mon, 31 Jul 2006 17:54:47 -0400 (EDT)


> It is up to clients of the event module to call "runHandlers"
>
>  val runHandlers: unit -> unit
>
> to run all scheduled handlers.  The expectation is not that user code
> is littered with calls to runHandlers.  Rather, the expectation is
> that the code that interfaces with the low-level asynchronous system
> stuff (select, GUI callbacks, etc.) calls runHandlers whenever system
> events enable new handlers.  At that point, a single call to
> runHandlers suffices to propagate all the effects of the low-level
> event throughout the SML world.

Do you have an idea of what this low-level asynchronous system "interface" 
should look like?  This seems to me to be where a lot off issues are 
likely to hide.  Off the top of my head, it seems that you need some sort 
of event loop that will continually poll all of the I/O related events, 
enabling them when appropriate.  It isn't clear to me that this sort of 
event loop won't require the main program to be written in the "inverted 
program structure" criticized by Reppy [Concurrent Programming in ML, p. 
145].  It is probably the case that higher-order functions in ML make this 
a little easier than it might be in a language like C, but without 
preemption, the programmer must be careful about long running code 
executing in handlers.