On Wed, Nov 1, 2017 at 12:37 PM, Colin Walters <walters@verbum.org> wrote:

> On Wed, Nov 1, 2017, at 03:02 PM, Shawn Landden wrote:
> >
> > This solves the fact that epoll_pwait() already is a 6 argument (maximum
> allowed) syscall. But what if the process has multiple epoll() instances in
> multiple threads?
>
> Well, that's a subset of the general question of - what is the interaction
> of this system call and threading?  It looks like you've prototyped this
> out in userspace with systemd, but from a quick glance at the current git,
> systemd's 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).
>
I think just setting it globally will work for 99.99% of cases, where there
is only one event loop, but I'd like to handle 100% of cases.
Unfortunately, epoll_pwait() is one of those cases, and that only will work
through a prctl() because of limited support for 7 arguments.

>
> 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 idle.
>