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

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

On Mon, 2007-08-27 at 01:47 +0200, Daniel Bünzli wrote:
> Le 25 août 07 à 17:29, skaller a écrit :
> 
> > There is something I don't understand here.
> 
> What you don't understand is that ocaml has a runtime system which  
> leaves some room for designing around what exists at the os level.

I do understand that, but it doesn't make any difference
to the fact that if you're running OS threads you need to use
OS facilities to support things like cancellation.

Also I at least would not like to see some extra feature dependent
on the current uniprocessor model, so hooking, say, the gc,
or the global lock, may be a bad idea because in a future multiprocessor
execution model those things may not be present.

> > If the source of the problem is a blocking operation, the solution
> > is simple: don't use blocking operations!
> 
> This is not the source of the problem. What I want is to allow users  
> to initiate and cancel computations whenever they want.

That is a reasonable crude idea, but not precise because you haven't
specified what 'should' happen to any acquired resources which would
normally be released under program control.

>  Computations  
> can be lengthy even tough they do not invoke a blocking operation.

Agree.

> The problem is that libraries are not -- and should not -- be  
> designed with cancellation in mind, say every function has an  
> optional parameter that allows to stop the computation.

I cannot agree with that claim at this time. If a library
acquires resources and should support cancellation, then the library
must also make provision for relinquishing those resources,
including on cancellation.

It is a fact, that in C++ libraries have to be designed to handle
unexpected *synchronous* exceptions.. they even have a term for it:
'exception safe', and it has a heavy influence on library design.

So the actual evidence is that you're not correct: libraries DO
have to be designed to allow for abnormal termination.

Synchronous exception handling is part of Ocaml. Asynchronous
exception handling is not. So whilst with synchronous exceptions
you can expect the program to catch and deal with the exceptions
because they're thrown by the users code in the first place,
or at least a library documenting that this may happen,
being able to handle async exceptions is likely to be an impediment
to programming in a way that manages resources safely.

I do know something about this -- I am responsible for an official
National Body "veto" on the C++ Standard on this issue. 
(Exception safe coding support) Note that is just ordinary
exception handling, particularly in a polymorphic context
where you can't know what exceptions will be thrown.. we're
still talking about synchronous exceptions.

I have no doubt async exceptions will also influence
library design.

>  Cancellation  
> should be a service of the runtime system, and denying its usefulness  
> because it could be misused makes no sense, I can also open a file  
> and never close it, it is a matter of programming discipline.

I'm not denying usefulness, I believe I simply claimed it couldn't
be implemented.

The problem here is roughly that OS support automatic release
of many resources held by a process, when the process is killed.
But there is no corresponding support for threads.

This issue arises EVEN for cancellation of Posix threads at
defined cancellation points. C executes 'on exit' procedures.
For C++ the issue has been a matter for years of study by
subgroups of the ISO Standardisation committee. Also those
responsible for system ABI's actually HAD to specify some kind
of behaviour, including the answer to the question: what happens
if an exception hits the bottom of a thread stack?

Note that the issue is nontrivial. For example if you DO execute
code after cancellation .. what happens on if there is a subsequent
cancellation? What happens if the cancellation code blocks?

I guess my point is: you're asking something difficult, even
for OS design, and reflecting it in Ocaml is going to be even
more problematic.

To make progress here you might instead consider a hybrid solution.
For example, Ocaml provide ability set a hook into the garbage
collector. That may be a bad idea, I don't know. Perhaps with a hook
you can complete a solution for certain kinds of application on 
certain OS, without imposing the responsibility for a complete
solution on Inria.


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