Re: [Caml-list] Has the thread cancellation problem evolved ?

[skaller <skaller@users.sourceforge.net>]

On Sat, 2007-08-25 at 15:58 +0200, Daniel Bünzli wrote:
> Hello everybody,
> 
> I would like to raise again the problem of portable thread  
> cancellation.

There is something I don't understand here.

Thread cancellation is a function of the native operating
system. You mention

> Thread cancellation allows to invoke an arbitrary function f on a  
> thread and stop its execution before completion,

and no operating system I know supports that. Posix, for example
allows cancelling a thread ONLY at specified system calls,
typically blocking socket related ones. It also misses one
critical one (I forget which).

The only other way to cancel a thread on Posix is to send a 
signal and AFAIK there is no standardised signal to do that
(only for processes?)

So you're asking Xavier to implement something impossible.
It can't be done in native code in the first place, forget
about safely. Futhermore:

> [5] by Gerd Stolpmann is  
> portable. Note however that neither solution will work with  
> uncooperative threads, i.e. those that never perform any system call  
> or trigger the gc [7].

And it is almost certainly not portable. Portable means on ALL
operating systems .. including Windows.

> I would appreciate having "Thread.raise_in" implemented, with the  
> system call caveat properly documented, instead of having to resort  
> to [5]. There is no feature request about this in the bug tracker.  
> Before filling a potentially useless one I would like to know what  
> you think about these problems and if there are things I have missed.

The general solution to this problem is to kill the whole process.
This ensures resources are cleaned up at the OS level, if not
the user level.

BTW: you can say "this isn't feasible for a web server" and I can
reply "No, and neither is destroying a thread out of the thread pool".

Otherwise, somewhere somehow there has to be a check done: whether
it is by the OS, by the Ocaml gc, or some user function.

Throwing an Ocaml exception is a very bad idea as a response!
It isn't just that resources won't be cleaned up .. it could
happen in the middle of C code interfacing Ocaml, and leave
the whole process in an inconsistent state (if the gc method
was used).

The bottom line is: there is necessarily NO safe way to clean
up a rogue thread, and if a thread does go rogue, the whole
process should be condemned.

If the source of the problem is a blocking operation, the solution
is simple: don't use blocking operations!

Otherwise, if your client thread is "cooperative" then checking
a cancellation flag at judicious points is tedious, but the best
solution.

What you REALLY want here is a Monadic combinator to automate
the checking .. :)

> P.S. If your computations need to interact with the ui, forking is  
> out of question.

It isn't out of the question, but is very nasty ;(


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net