asynchronous exceptions

Stephen Weeks MLton@sourcelight.com
Thu, 27 Jul 2000 10:57:32 -0700 (PDT)


I'm still working on implemention my timeLimit function, which has a
spec like

(* timeLimit(t, f) runs f() for at most t time.  It returns SOME if
 * f returns within time t and returns NONE otherwise.
 *)
val timeLimit: Time.t * (unit -> 'a) -> 'a option

I have two different ways the timeout could be handled.

(1) Evaluate f() in a separate thread, and throw away the thread 
   when time runs out.

(2) Evaluate f() in the current thread, and raise an exception
   (asynchronously) at the next limit check point.

Here are the tradeoffs as I see it.

(1) good
  - trivial to implement with current runtime
  - easy to reason about programs

(2) good
  - handlers get to clean up when f() times out

(2) bad
  - slight additional runtime cost for entering gc (and thread
    switching), because threads will have to check for an asynchronous 
    exception

I am interested to hear your opinions.  Am I insane for even
considering asynchronous exceptions?  I know they had them in SML/NJ
at some point (for SIGINT), but got rid of them, but I don't remember
why.