Static analysis of non-local transfers: a proposal
mark at twistedbanana.demon.co.uk
Tue Nov 25 03:24:56 PST 2008
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
>> 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
> 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
> 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.
More information about the closures-dev