On Sun, Jan 22, 2023 at 11:48 PM TheDiveO wrote:
>
> > On Sunday, January 22, 2023 at 12:18:34 AM UTC+1 Ian Lance Taylor wrote:
> > Using runtime.LockOSThread does not exempt the goroutine from GOMAXPROCS.
>
> I was asking to elaborate more on this previous answer of yours, as I
>
> On Sunday, January 22, 2023 at 12:18:34 AM UTC+1 Ian Lance Taylor wrote:
> Using runtime.LockOSThread does not exempt the goroutine from GOMAXPROCS.
I was asking to elaborate more on this previous answer of yours, as I
don'tunderstand yet how GOMAXPROCS relates to (preemptive?) go routine
On Sun, Jan 22, 2023 at 9:17 AM TheDiveO wrote:
>
> On Sunday, January 22, 2023 at 12:18:34 AM UTC+1 Ian Lance Taylor wrote:
> Using runtime.LockOSThread does not exempt the goroutine from GOMAXPROCS.
>
> Hi Ian, thank you very much for your answer! I'm afraid that I do not yet
> understand (due
On Sunday, January 22, 2023 at 12:18:34 AM UTC+1 Ian Lance Taylor wrote:
Using runtime.LockOSThread does not exempt the goroutine from GOMAXPROCS.
Hi Ian, thank you very much for your answer! I'm afraid that I do not yet
understand (due to my limited runtime knowledge) how to conclude from
On Sat, Jan 21, 2023 at 2:06 PM TheDiveO wrote:
>
> When a go routine gets locked to an OS thread, does the Go runtime scheduler
> then stops interrupting this Go routine, so when this Go routine (or rather
> the thread) gets pinned to an exclusive CPU core can make use of real time
>
When a go routine gets locked to an OS thread, does the Go runtime
scheduler then stops interrupting this Go routine, so when this Go routine
(or rather the thread) gets pinned to an exclusive CPU core can make use of
real time priorities?
--
You received this message because you are
