On Sun, Mar 14, 2021 at 7:54 PM Robert Engels <[email protected]> wrote:
>
> True. I was collapsing the two because why does Go care. If the routine is in 
> a C native call don’t switch the routine assigned to the thread. Similarly. 
> If the thread is in C native it can’t affect stacks / heap structures - so 
> routines that make C calls only need to ensure a C minimum stack size. The 
> state I was referring to supports the determination of “is running  native” 
> and if so “leave it alone” until it returns to Go code. As long as the 
> pointers passed to the C code are either native (non heap) or tracked the C 
> code is “safe”.
>
> So to that point, it’s confusing as to why the scheduler is the bottleneck in 
> calling C code.

Go uses a cooperative goroutine scheduler; even the signal based
preemption that we use now amounts to a mechanism for telling the
goroutine to cooperate.  A goroutine that is running C code is not
cooperating with the scheduler.  If the scheduling code is not aware
of that, it is easy for a blocking C function to block the entire
program, even if there are other runnable goroutines.

I think it is too strong to say that the scheduler is the "bottleneck"
in calling C code, but I believe that the operations required to tell
the scheduler what is happening to the goroutine are the most costly
parts of a call into C code.

I should clarify that I am not saying that this is some inherent
problem that can't be fixed.  I'm saying that this is true in today's
implementation.  If we want to speed up calls to C code--and, of
course, we do--then we should be looking at reducing this overhead of
communicating with the scheduler.  We should not be looking at the
different calling convention or the change of stacks, because those,
while not entirely free, are not the heaviest cost in the current
implementation.

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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXRgv6b9oiVRjyFOdqmTfcp762NVWyRgnTK%2Bga6_6cvJQ%40mail.gmail.com.

Reply via email to