News for hackers. Stuff that matters.

A comment on Proposal: Non-cooperative goroutine preemption. Parent comment

Re:Proposal: Non-cooperative goroutine preemption by jashmatthews on Thursday March 29, 2018 @09:39AM (#16706921)
Simply using 1,000+ OS threads is often very close to as efficient as using coroutines or an event loop: https://www.slideshare.net/e456/tyma-paulmultithreaded1
[ Parent | on HN ]
Re:Proposal: Non-cooperative goroutine preemption by zzzcpan on Thursday March 29, 2018 @09:46AM (#16706974)
If your event loop is as slow as 1000+ coroutines or OS threads, you are doing it very very wrong.
[ Parent | on HN ]
Re:Proposal: Non-cooperative goroutine preemption by jashmatthews on Thursday March 29, 2018 @09:52AM (#16707026)
AFAIK the main benefit to coroutines is getting to manually manage tiny stacks.

For example, in Go, they mark a goroutine's stack as "hasn't executed since the last time we marked", which makes GC with thousands of threads a lot faster.

[ Parent | on HN ]
Re:Proposal: Non-cooperative goroutine preemption by arghwhat on Thursday March 29, 2018 @09:54AM (#16707042)
[Citation needed]
[ Parent | on HN ]
Re:Proposal: Non-cooperative goroutine preemption by jashmatthews on Thursday March 29, 2018 @10:35AM (#16707370)
https://github.com/golang/go/issues/12061

"Mark termination does not have to rescan stacks that haven’t executed since the last scan"

With pre-emptive scheduling of OS threads, you potentially dirty a ton more stacks, and have to scan them all for pointers to heap memory. I'm not sure how VMs using lots of OS threads deal with this.

[ Parent | on HN ]