Static analysis of non-local transfers: a proposal

[Mark Mahieu]

On 24 Nov 2008, at 12:58, John Longley wrote:

> The concurrency examples are very interesting. Mark wrote:
>
>> I interpreted John's proposal as really being targeted at the 'late
>> transfer' rather than 'wrong thread' form, and as such the
>> restrictions shouldn't prevent the deliberate use of   
>> UnmatchedTransfer
>> for the creation of APIs like 'for eachConcurrently'.
>
> Yes, that's how I see it. One possible approach might be simply to  
> accept that my proposal doesn't exclude UnmatchedTransfer in  
> concurrent situations. This mightn't seem so bad if the idea is  
> that the clever concurrent stuff is written once-for-all by an  
> expert who knows what they're doing and then stuck in an API.

That's the idea.  The two uses of UnmatchedTransfer are very  
different in my view; the 'late transfer' form is almost certainly  
due to programmer error, whilst the 'wrong thread' form is actually  
useful to the implementation of these concurrent APIs, and provides a  
method to help do the right thing.  In some ways, it might be clearer  
if they were different classes, perhaps with the 'late' form  
manifested as an Error rather than an Exception.

So I think that excluding the 'wrong thread' forms is precisely  
what's required, rather than something that should be accepted as a  
limitation.

> The crucial lines of code for handling these transfers (taken from  
> Mark's blog) are
>
>       if (throwable instanceof UnmatchedTransfer)
>            throw ((UnmatchedTransfer) throwable).transfer();
>
> Although I don't understand exactly how this works, I imagine that  
> returning control to the correct thread is pretty much *always*  
> what one wants to do in practice.

Almost; to be pedantic, you'd either choose to attempt to restart the  
transfer in the correct thread (which may still fail due to it being  
a 'late transfer' of course), or you'd choose to discard it,  
typically because you may encounter many UnmatchedTransfers but can't  
restart more than one.

> So perhaps there is also a more sophisticated approach which would  
> build in this behaviour somehow - e.g. any concurrent code  
> involving closures is treated as implicitly having a handler like  
> the above, so that it's still guaranteed that the programmer never  
> sees an UnmatchedTransfer? (I haven't thought this through in detail.)

There probably is, but I found it works very well as it is now.  I'm  
sure my example implementation can be improved upon, but when  
implementing such APIs you'd usually also want to handle other  
Exceptions that are raised anyway by rethrowing them in the correct  
thread.  Once you've got the code written to deal with that (which  
accounts for almost all of the complexity), handling non-local  
transfers via UnmatchedTransfer just slots right in, with the only  
difference being that you call the transfer() method on it, rather  
than rethrowing.

> As a further point, I'd also like to describe how I think my  
> proposal can simplify the tracking of exceptions, but I'll save  
> this for another message.

Sounds intriguing; looking forward to hearing about it!

>
> Cheers, John
>
>
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>

Best regards,

Mark