interaction between runtime scheduler and Cgo calls

[Dan Kortschak]

This sort of follows on from the EINTR discussion a while back, but was
prompted by a claim in the gophers #general slack channel that "the Go
scheduler will actively try to interrupt CGO calls that take too
long"[1].

This doesn't seem right to me, but I wanted to confirm from people who
know (also is there any documentation about the behaviour of the new
pre-emptive scheduler?).

thanks
Dan

[1]
https://gophers.slack.com/archives/C0UKS8V9S/p1583511112030900?thread_ts=1583487810.024900&cid=C0UKS8V9S

[Ian Lance Taylor]

On Fri, Mar 6, 2020 at 1:40 PM Dan Kortschak <d...@kortschak.io> wrote:
>
> This sort of follows on from the EINTR discussion a while back, but was
> prompted by a claim in the gophers #general slack channel that "the Go
> scheduler will actively try to interrupt CGO calls that take too
> long"[1].
>
> This doesn't seem right to me, but I wanted to confirm from people who
> know (also is there any documentation about the behaviour of the new
> pre-emptive scheduler?).

There is a sense in which it is right. When a cgo call starts it has
a P attached to it (in the scheduler, a P is a virtual processor;
there are exactly GOMAXPROCS P's at all times). If the cgo call
completes quickly, it will simply carry on with the same P. When the
system monitoring thread wakes up, it will check each P to see if it
has been waiting for a cgo call to complete for more than a scheduler
tick (20 microseconds, more or less). If so, the P will be stolen and
some other M (operating system thread) will be woken up to start using
the P and running Go code. When the cgo call completes, the goroutine
will see that it no longer has a P, and will go to sleep waiting for a
P to become available (more or less as though the goroutine called
runtime.Gosched).

So in that sense, cgo calls will be interrupted: the P will be removed
and reassigned to do other work.

However, the actual C code running on the M (operating system thread)
will not be affected. And the G (goroutine) will of course remain
asleep waiting for the cgo call to complete.

(This is all a description of the current 1.14 scheduler, and it may
be different in other releases.)

Ian

[Dan Kortschak]

Thanks, Ian.