News for hackers. Stuff that matters.

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

Re:Proposal: Non-cooperative goroutine preemption by vidarh on Thursday March 29, 2018 @09:31AM (#16706847)
> You can't easily spawn 10.000 OS threads.

I just spawned 10.000 OS threads running separate mRuby instances in each thread on my laptop, to see if it'd cause any problems (because I happened to have an app sitting around that spawns separate threads; note: these are not Ruby threads, mRuby does not have built in threading). None at all. So yes, you can. I didn't check how much memory it'd take, however, or attempt to measure overheads in any way, so I'm not saying there aren't potential issues with it.

[ Parent | on HN ]
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 ]
Re:Proposal: Non-cooperative goroutine preemption by coldtea on Thursday March 29, 2018 @10:42AM (#16707433)
>So yes, you can. I didn't check how much memory it'd take, however, or attempt to measure overheads in any way, so I'm not saying there aren't potential issues with it.

The "easily" part wasn't referring to feasibility, but to how effortless it is to do AND have performance and scalable code.

[ Parent | on HN ]