On Mon, 8 Oct 2018 at 16:30, Ian Lance Taylor wrote:
> On Mon, Oct 8, 2018 at 4:50 AM, Scott Cotton wrote:
> 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
On Mon, Oct 8, 2018 at 4:50 AM, Scott Cotton 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 wrote:
>> >
>> > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote:
>> >>
>> >> On Fri, Oct 5, 2018 at 2:10 PM, Scott Co
Thanks,
This doesn't however really address what I was pointing out. Maybe I was
too vague, let me try to clarify.
Suppose you are working on an operating system port of something and you
use sys calls. You check the syscall package, the OS docs, and you need to
execute a sequence of sys cal
On Mon, Oct 8, 2018 at 1:50 PM Scott Cotton wrote:
> 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 sequen
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 > wrote:
> >
> > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor > wrote:
> >>
> >> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton > wrote:
> >
> >
> >>
> >> In fact
> >> we
On Fri, Oct 5, 2018 at 11:57 PM, Scott Cotton wrote:
>
> On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote:
>>
>> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton wrote:
>
>
>>
>> In fact
>> we definitely do want to add other preemption checks that occur at
>> points other than function entry (iss
On Fri, Oct 5, 2018 at 11:40 PM, Scott Cotton wrote:
>
> On Sat, 6 Oct 2018 at 02:10, Ian Lance Taylor wrote:
>>
>> On Fri, Oct 5, 2018 at 3:21 PM, Scott Cotton wrote:
>> >
>> > On Fri, 5 Oct 2018 at 23:46, Scott Cotton wrote:
>> >>
>> >> Thanks much for the info.
>> >>
>> >> Do you have any mo
On Sat, 6 Oct 2018 at 08:57, Scott Cotton wrote:
>
>
> On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote:
>
>> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton wrote:
>>
>
>
>> In fact
>> we definitely do want to add other preemption checks that occur at
>> points other than function entry (issue
On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote:
> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton 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, t
On Sat, 6 Oct 2018 at 02:10, Ian Lance Taylor wrote:
> On Fri, Oct 5, 2018 at 3:21 PM, Scott Cotton wrote:
> >
> > On Fri, 5 Oct 2018 at 23:46, Scott Cotton wrote:
> >>
> >> Thanks much for the info.
> >>
> >> Do you have any more pointers about how one may assess whether or ensure
> >> that a
On Fri, Oct 5, 2018 at 3:21 PM, Scott Cotton wrote:
>
> On Fri, 5 Oct 2018 at 23:46, Scott Cotton 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 di
On Fri, Oct 5, 2018 at 3:06 PM, Tyler Compton wrote:
>
> 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.
Directives like //go:no
On Fri, Oct 5, 2018 at 2:46 PM, Scott Cotton wrote:
>
> 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?
You basically have to know what you're doing. In the general case,
whether go:n
On Fri, 5 Oct 2018 at 23:46, Scott Cotton 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?
>
Perhaps the compiler automatically accounts for the
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 wrote:
> Thanks much for the info.
>
>
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 wrote:
> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton wro
On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton 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 specifie
Hi all,
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 inc
18 matches
Mail list logo
