Notes on structured concurrency, or: Go statement considered harmful • Hacker News Board

Re: Notes on structured concurrency, or: Go statement considered harmful

#231

Post by wokwokwok » Mon, Apr 30, 2018, 11:49 PM UTC

joshuamorton wrote: post #211

wokwokwok wrote: post #197

Earlier quoted context omitted.

> they cannot and do not have. sigh~ In this implementation, or perhaps, in python at all... Does that make it completely valueless? I would venture to suggest that maybe there's a big wide world of languages that actually support controlling how threads are spawned, where it might not be. Maybe its worth considering.

Or perhaps at all. I agree that it's worth considering other ways of handling concurrency. But we should do so by staying within the realm of reality. Your understanding of nurseries, conceptually, does not match their capabilities. It's not about any language or implementation, it's that what you think they can do isn't possible. It violates the halting problem. You can't statically infer whether or not a function w…

You are simply not correct.

If you can control how threads spawn, like C# thread contexts (for example the MVC context forces async resumes on the original thread rather than an arbitrary one), this is entirely plausible without an 'opt in' model.

Re: Notes on structured concurrency, or: Go statement considered harmful

#232

Post by joshuamorton » Mon, Apr 30, 2018, 11:56 PM UTC

wokwokwok wrote: post #231

joshuamorton wrote: post #211

Earlier quoted context omitted.

Or perhaps at all. I agree that it's worth considering other ways of handling concurrency. But we should do so by staying within the realm of reality. Your understanding of nurseries, conceptually, does not match their capabilities. It's not about any language or implementation, it's that what you think they can do isn't possible. It violates the halting problem. You can't statically infer whether or not a function w…

You are simply not correct. If you can control how threads spawn, like C# thread contexts (for example the MVC context forces async resumes on the original thread rather than an arbitrary one), this is entirely plausible without an 'opt in' model.

>If you can control how threads spawn

This is an opt in model.

In general, it is not possible to know if an arbitrary thread will halt. That's the halting problem. You can restrict yourself and make sure that all threads 'return' on completion (promises, futures), or do various other things. But in an unrestricted system, it is provably impossible to know whether or not an arbitrary thread will halt.

Re: Notes on structured concurrency, or: Go statement considered harmful

#233

Post by wokwokwok » Tue, May 01, 2018, 3:00 AM UTC

joshuamorton wrote: post #232

wokwokwok wrote: post #231

Earlier quoted context omitted.

You are simply not correct. If you can control how threads spawn, like C# thread contexts (for example the MVC context forces async resumes on the original thread rather than an arbitrary one), this is entirely plausible without an 'opt in' model.

>If you can control how threads spawn This is an opt in model. In general, it is not possible to know if an arbitrary thread will halt. That's the halting problem. You can restrict yourself and make sure that all threads 'return' on completion (promises, futures), or do various other things. But in an unrestricted system, it is provably impossible to know whether or not an arbitrary thread will halt.

The issue is waiting for threads at runtime, at fixed boundary points, not statically determining if they halt or not.

The halting problem is irrelevant to this discussion.

Well.. whatever. You can provably determine whatever irrelevant point you want I guess.

If a naively spawned task or routine can be artificially restricted at a boundary point, that's enough for me.

You could without question implement this by binding child tasks to the threadlocal context on spawn and wait all on a dispose block in c#; certainly if you explicitly went out of your way to swap to a different sync context it would break but so what?

You can always unsafe your way into a hole in any language.

Re: Notes on structured concurrency, or: Go statement considered harmful

#234

Post by joshuamorton » Tue, May 01, 2018, 3:26 AM UTC

wokwokwok wrote: post #233

joshuamorton wrote: post #232

Earlier quoted context omitted.

>If you can control how threads spawn This is an opt in model. In general, it is not possible to know if an arbitrary thread will halt. That's the halting problem. You can restrict yourself and make sure that all threads 'return' on completion (promises, futures), or do various other things. But in an unrestricted system, it is provably impossible to know whether or not an arbitrary thread will halt.

The issue is waiting for threads at runtime, at fixed boundary points, not statically determining if they halt or not. The halting problem is irrelevant to this discussion. Well.. whatever. You can provably determine whatever irrelevant point you want I guess. If a naively spawned task or routine can be artificially restricted at a boundary point, that's enough for me. You could without question implement this by bin…

>If a naively spawned task or routine can be artificially restricted at a boundary point, that's enough for me.

Ok, and you have three options to do this:

1. Block 2. Opt into some system that allows you to defer blocking until later 3. Know when the callback will finish

1 isn't async, 2 is an opt in system, and 3 has a prerequisite of the halting problem.

That's it. You can restrict yourself to not using primitives like `Thread`, and instead only use futures or async/await style things, and that's a valid solution. Hell, your language could not expose a Thread primitive at all. But its solution #2. You cannot just take a look at arbitrary code and pick a point or points where thread execution is restrained.

If you can, it's because the language you're using prevents you from doing certain things. (for example, opting in to "all threads must be promises, and all promises must be awaited)