stack-bound vs. travelling closures proposal

[Jesse Kuhnert]

What are these use cases then which require all of the throws noise
which is so troubling? Even back in the day when our using jini based
I/o protocol to communicate multiple device node state in a shared
environment was supposed to be uber cool top of the line
javaspace/jini impl of "grid" computation do I remember exceptions as
being anything other than a minor syntax distraction from the general
goal. (of never being unavailable and above all never losing data)

I'm just curious is all, having implemented life-critical concurrent
systems (Doug Lea's library was like a beacon of light at the time) in
the most intense/demanding software environments in all hospital
operating related areas as to how your silly stack vs some other state
approach really resolves the core problem at all or you are just
talking to stroke your own ego. Just curious, that's all. It's not
like you've had to live by your silly assertions or anything at all
yet right? Talk to me when the phone rings at
it-doesn't-matter-make-it-work and then I'll believe.

On Friday, June 18, 2010, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> Using concurrency is not the problem. It's writing the libraries. I'm
> working on the theory that the number of people engaged in writing low-level
> concurrency libraries is limited. Get it right once, in other words.
>
> strawman makes using these libraries more difficult because most SAM types
> will have to be retired to support 'throws E'. It also makes writing utility
> functions that don't themselves engage in concurrency (though they can of
> course use received closures as arguments to concurrent utilities) far
> harder than stack-bound; stack-bound actually gives exception transparency
> to such functions for the mere cost of adding 1 keyword to the appropriate
> parameter.
>
> --Reinier Zwitserloot
>
>
>
> On Fri, Jun 18, 2010 at 6:42 AM, Neal Gafter <neal at gafter.com> wrote:
>
>> On Thu, Jun 17, 2010 at 6:12 PM, Reinier Zwitserloot
>> <reinier at zwitserloot.com> wrote:
>> > Parellizing sort can be done in a similar way to the example
>> implementation
>> > of forEachParallelized.
>> > Yes, it's ugly, and involves both unshackle and sneakyThrow, but it would
>> > work just fine.
>>
>> Recall that better concurrency support is one of the motivations for
>> adding lambda.  If the language forces programmers to undermine the
>> type system (or exception checking system) in order to use
>> concurrency, then we've failed.
>>
>
>