I'm also surprised to hear that go:nosplit can be used in arbitrary packages. I would be curious to know if these directives are covered under the compatibility promise within the limited guarantees they provide.
On Fri, Oct 5, 2018 at 2:47 PM Scott Cotton <w...@iri-labs.com> wrote: > Thanks much for the info. > > Do you have any more pointers about how one may assess whether or ensure > that a stack overflow check > is not necessary in order to safely use this directive? > > Scott > > > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor <i...@golang.org> wrote: > >> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton <w...@iri-labs.com> wrote: >> > >> > I have for the longest time thought of "go:nosplit" as a >> runtime-specific >> > thing which wasn't available to arbitrary package authors. >> > >> > Then, I found this from "go doc compile" >> > >> > ``` >> > //go:nosplit >> > >> > The //go:nosplit directive specifies that the next function declared in >> the >> > file must not include a stack overflow check. This is most commonly >> used by >> > low-level runtime sources invoked at times when it is unsafe for the >> calling >> > goroutine to be preempted. >> > ``` >> > >> > I am interested in knowing >> > 1. Can it indeed be used in arbitrary packages? >> >> Yes. >> >> > 2. Does it indeed prevent the emission/addition of pre-emption >> instructions >> > in the function it annotates? >> >> Well, yes and no. What it does is disable the stack overflow check at >> function entry. At present the stack overflow check is also used as >> a goroutine-preemption check. So disabling the stack overflow check >> disables the goroutine-preemption check at function entry. And in Go >> 1.11 that is the only preemption check, so in Go 1.11 go:nosplit does >> indeed disable preemption for a function. But there are no promises >> that there will never be any other sort of preemption check. 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. >> >> > 3. Can it be used with gccgo? >> >> Yes. >> >> Ian >> > > > -- > Scott Cotton > http://www.iri-labs.com > > > -- > 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. > -- 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.
