>> It ought to be impossible, because printlock increments mp.locks.
Thanks, realized it's NOT a problem with printlock/printunlock.
>> Have you seen this happen?
Not yet with normal program, but a deadlock could be produced with the
diagnostic change to mgcsweep.go (say, running ./make.bash
>> Have you seen this happen? It ought to be impossible, because
>> printlock increments mp.locks. When mp.locks is not zero the M can't
>> be preempted and the goroutine can't block.
Not yet with normal program, but a deadlock could be produced with the
diagnostic change to mgcsweep.go (say, run
On Wed, Feb 22, 2023 at 6:43 PM Xiangdong Ji wrote:
>
> Looks like the print* helper functions may run into deadlocks if the printer
> Goroutine is rescheduled to a different M to execute 'printunlock' as the "if
> mp.printlock==0" checking is likely to fail if M has changed.
Have you seen this
Hi experts,
Looks like the print* helper functions may run into deadlocks if the
printer Goroutine is rescheduled to a different M to execute 'printunlock'
as the "if mp.printlock==0" checking is likely to fail if M has changed.
Wondering is it intentional behavior? As print* are (almostly if n
