Whither structured concurrency?

[Andrew Haley]

On 11/13/19 9:00 PM, John Rose wrote:
> On Nov 13, 2019, at 12:58 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 11/12/19 7:18 PM, Alan Bateman wrote:
>>> On 12/11/2019 18:50, Andrew Haley wrote:
>>>> :
>>>> OK, so I don't see how I can move forward with scoped locals because
>>>> I have nothing to test on.
>>>>
>>> I think having scoped locals that are values accessible and shared by 
>>> many threads is a topic in itself. I don't think that should stop us 
>>> making progress on getting scoped locals working initially with 
>>> virtual/lightweight threads, right?
>>
>> Sure, that's true. I can still progress with making inheritance work
>> correctly with virtual/lightweight threads.
> 
> I think you are designing them as values rather than variables,
> which means they are easier to share/inherit safely, without
> races.  If they were variables, then they would have to be
> copied into each fiber if there were any possibility of setting.
> By contrast, a whole environment full of shared values can
> be inherited with as little overhead as a single pointer.

That's not entirely true because if the parent thread continues to run
-- which happens with Threads but not with structured concurrency --
then the parent's set of bound locals changes, even though the values
themselves do not. Therefore there is no choice but to clone the set
at the point of (light or heavy) thread creation. When structured
concurrency returns there will be no need to do this, so a pointer
will suffice.

> Note that legacy TLs are designed as variables, with a TL::set
> operation.  Their overheads are only excusable because they are
> shadowed by the dino-sized appetite for resources of classic
> threads.  I’m glad we’re not repeating this pattern with fibers; it
> would be a mistake.

Indeed!

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671