On Mon, Oct 8, 2018 at 4:50 AM, Scott Cotton <w...@iri-labs.com> wrote: > > 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> wrote: >> > >> > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor <ia...@golang.org> wrote: >> >> >> >> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton <w...@iri-labs.com> 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.
I think that you are correct: given a sequence of system calls, the Go language does not guarantee that there will be no intervening system call. That is true today and it will be true in the future. For example, today, the Go language makes no specific guarantees about when memory will be allocated, and therefore makes no specific guarantees about when the mmap system call will be called (on Unix systems). But the concern about a sequence of system calls that admits no intervening system call seems rather abstract to me. When does that issue ever arise? That's not your real concern. Your real concern has to do with running audio code without interruption. That concern, too, is abstract. We don't know how well it works today and we don't know how well it will work in the future. Let's focus on real problems. The lack of cooperative preemption is giving us real problems in real Go programs today. That is why we are trying to fix it. If the fix causes problems for audio code, then we'll try to fix that. But let's not get ahead of ourselves; let's first see if there is a problem. 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.
