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

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

On Mon, 2007-08-27 at 12:12 +0200, Daniel Bünzli wrote:
> Le 27 août 07 à 06:38, skaller a écrit :
> 
> > 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.
> 
> They are left as is. If the programmer didn't care to handle, this is  
> his problem, as when he forgets to close a file. The problem is if  
> you don't even give the opportunity to the programmer to handle the  
> problem, this is why Thread.kill is bad but Thread.raise_in acceptable.

I agree with you rationale, but it isn't clear the conclusion follows
that raise_in is acceptable.

To give a simple pseudo code:

	begin
		let f = open_out filename in
		write f stuff;
		close f
	end

which would work assuming write doesn't raise, will fail to
work in the presence of async exceptions. This roughly means
every resource acquisition MUST be guarded by a try/with
which catches the async exception and releases the resource
before re-raising it.

With a simple stack protocol this is fine .. but we use the
heap and garbage collectors because the stack isn't enough,
so presumably this protocol could be hard to follow.

In C++, RAIII is used for this, i.e. object whose constructors
acquire a resource and destructors release it, together with
say ref counted pointers, so that throwing an exception unwinds
all the objects, i.e. executes the destructors to release the
resources.

Ocaml has no such facility. SO before even considering raise_in
you need to propose one: possibly this would involve a monadic
programming style, but I don't really know.

I would guess, adding async exceptions, plus a requirement
to properly manage resources, could have a radical impact
on acceptable library designs.

Please note this is a guess. I don't know. But I think before
even asking for async exception, you'd need at least one
proposal to handle them.

> > 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.
> 
> I think that in gc'd environment this problem is less acute. 

That may be so, on the assumption calls to the gc are frequent,
which sounds fairly reasonable to me.

> How many  
> of the libraries out there are using locks or do fd business I don't  
> know _under_ the module interface ? Any library that does not perform  
> that kind of thing, and to overapproximate that does not bind to C,  
> won't have a problem with cancellation. If their resource usage is  
> explicit then I'm writing the resources allocation and deallocation  
> and my thread will release them in the exception handler that I will  
> write. I'll design and care for it.

It is not so simple I suspect .. you can put an exception handler
at the start of the thread, but then how do you know what resources
to release?

If there is a registry of them .. all the routine allocating resources
must use the registry.

The problem is try/raise/with is a stack protocol: you cannot wrap
allocations in it, if the allocation returns the resource.

I'm not saying there is no solution.. but if you have libraries,
particularly ones with HOFs, then you have to actually have a
standardised protocol that all the libraries have to follow.


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