On Monday, 8 October 2018 06:02:13 UTC+2, Ian Lance Taylor wrote: > > On Fri, Oct 5, 2018 at 11:57 PM, Scott Cotton <w...@iri-labs.com > <javascript:>> wrote: > > > > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > >> > >> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton <w...@iri-labs.com > <javascript:>> wrote: > > > > > >> > >> In fact > >> we definitely do want to add other preemption checks that occur at > >> points other than function entry (issues #10958, #24543). And if > >> there is another preemption check, there are no promises that > >> go:nosplit will disable that check. > > > > > > From what I understand, this would > > 1. enable more faire/balanced scheduling > > 2. reduce worst case gc latency > > 3. eliminate problems when programmers unintentionally spin with > > cooperative/stack based > > pre-emption. > > 4. slow things down a bit when fair/balanced scheduling and gc latency > and > > 3) are not an issue > > 5. make it impossible to prevent pre-emption in cases that need it or > rely > > on cooperative/stack based pre-emption > > 6. potentially re-order some sequences of system calls, so that Go > > programmer sequences of system calls G1, G2, ... > > may have Go runtime system calls inserted in between where they weren't > > previously. > > > > I don't think anyone wants 4,5 and 6 is frightening. > > > > Maybe I don't know what I'm doing, so perhaps others can give opinions? > > > > Or should this discussion be on the issue tracker or golang-dev? > > See the discussion at issue #24543. With that scheme 4 should not be > an issue. 5 and 6 could be problems in principle, but note that there > is no guaranteed way to do that today either. >
Thanks. Continuing the discussion here since there re no responses there for some time. There are many different ways to interpret "guaranteed" above. The two that come to mind are a) A single given go release implementation, such as go1.11 actually may randomly pre-empt outside of cooperative/stack based premption. My understanding is no, you do not mean this. And that cooperative/stack based pre-emption has been an established norm for a long time even if it falls outside the formal language specification. I call it a language "semantic" because to me it's not really the same level of abstraction as say whether the compiler does loop unrolling. It has qualitative program I/O implications. b) If, by "guaranteed" you mean that the language does not formally specify it, then I take it on faith that you know the specification better than I, so ok. However, I wanted to state that if the language doesn't specify this, and the language also doesn't specify what sys-calls are used on what platforms in what circumstances, then one can readily conclude that any Go program that relies on sequences of sys-calls longer than length one is in fact not guaranteed to work either. While I appreciate being conservative about the language spec and compatibility, I find this conundrum quite impractical. Scott > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
