On Wed, 2017-11-01 at 15:37 -0400, Colin Walters wrote: > threading is limited doing sync()/fsync() and gethostbyname() async. > > But languages with a GC tend to at least use a background thread for > that, > and of course lots of modern userspace makes heavy use of > multithreading > (or variants like goroutines). > > A common pattern though is to have a "main thread" that acts as a > control > point and runs the mainloop (particularly for anything with a GUI). > That's > going to be the thing calling prctl(SET_IDLE) - but I think its idle > state should implicitly > affect the whole process, since for a lot of apps those other threads > are going to > just be "background". > > It'd probably then be an error to use prctl(SET_IDLE) in more than > one thread > ever? (Although that might break in golang due to the way goroutines > can > be migrated across threads) > > That'd probably be a good "generality test" - what would it take to > have > this system call be used for a simple golang webserver app that's > e.g. > socket activated by systemd, or a Kubernetes service? Or another > really interesting case would be qemu; make it easy to flag VMs as > always > having this state (most of my testing VMs are like this; it's OK if > they get > destroyed, I just reinitialize them from the gold state). > > Going back to threading - a tricky thing we should handle in general > is when userspace libraries create threads that are unknown to the > app; > the "async gethostbyname()" is a good example. To be conservative > we'd > likely need to "fail non-idle", but figure out some way tell the > kernel > for e.g. GC threads that they're still I realize none of this is a problem because when prctl(PR_SET_IDLE, PR_IDLE_MODE_KILLME) is set the *entire* process has declared itsself stateless and ready to be killed.
