On 11/01/2017 04:22 PM, Colin Walters wrote:
>
> On Wed, Nov 1, 2017, at 11:16 AM, Colin Walters wrote:
>> as the maintainer of glib2 which is used by a *lot* of things; I'm not
> (I meant to say "a" maintainer)
>
> Also, while I'm not an expert in Android, I think the "what to kill" logic
> there
On 11/01/2017 04:22 PM, Colin Walters wrote:
>
> On Wed, Nov 1, 2017, at 11:16 AM, Colin Walters wrote:
>> as the maintainer of glib2 which is used by a *lot* of things; I'm not
> (I meant to say "a" maintainer)
>
> Also, while I'm not an expert in Android, I think the "what to kill" logic
> there
[Always cc linux-api mailing list when proposing user visible api
changes]
On Tue 31-10-17 22:32:44, Shawn Landden wrote:
> It is common for services to be stateless around their main event loop.
> If a process passes the EPOLL_KILLME flag to epoll_wait5() then it
> signals to the kernel that
[Always cc linux-api mailing list when proposing user visible api
changes]
On Tue 31-10-17 22:32:44, Shawn Landden wrote:
> It is common for services to be stateless around their main event loop.
> If a process passes the EPOLL_KILLME flag to epoll_wait5() then it
> signals to the kernel that
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
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
On 2017/11/01 14:32, Shawn Landden wrote:
> @@ -1029,6 +1030,22 @@ bool out_of_memory(struct oom_control *oc)
> return true;
> }
>
> + /*
> + * Check death row.
> + */
> + if (!list_empty(eventpoll_deathrow_list())) {
> + struct list_head *l =
On 2017/11/01 14:32, Shawn Landden wrote:
> @@ -1029,6 +1030,22 @@ bool out_of_memory(struct oom_control *oc)
> return true;
> }
>
> + /*
> + * Check death row.
> + */
> + if (!list_empty(eventpoll_deathrow_list())) {
> + struct list_head *l =
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
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
On Wed, Nov 1, 2017, at 11:16 AM, Colin Walters wrote:
>
> as the maintainer of glib2 which is used by a *lot* of things; I'm not
(I meant to say "a" maintainer)
Also, while I'm not an expert in Android, I think the "what to kill" logic
there lives in userspace, right? So it feels like we
On Wed, Nov 1, 2017, at 11:16 AM, Colin Walters wrote:
>
> as the maintainer of glib2 which is used by a *lot* of things; I'm not
(I meant to say "a" maintainer)
Also, while I'm not an expert in Android, I think the "what to kill" logic
there lives in userspace, right? So it feels like we
On Wed, Nov 1, 2017, at 01:32 AM, Shawn Landden wrote:
> It is common for services to be stateless around their main event loop.
> If a process passes the EPOLL_KILLME flag to epoll_wait5() then it
> signals to the kernel that epoll_wait5() may not complete, and the kernel
> may send SIGKILL if
On Wed, Nov 1, 2017, at 01:32 AM, Shawn Landden wrote:
> It is common for services to be stateless around their main event loop.
> If a process passes the EPOLL_KILLME flag to epoll_wait5() then it
> signals to the kernel that epoll_wait5() may not complete, and the kernel
> may send SIGKILL if
On Tue, Oct 31, 2017 at 10:32:44PM -0700, Shawn Landden wrote:
> It is common for services to be stateless around their main event loop.
> If a process passes the EPOLL_KILLME flag to epoll_wait5() then it
> signals to the kernel that epoll_wait5() may not complete, and the kernel
> may send
On Tue, Oct 31, 2017 at 10:32:44PM -0700, Shawn Landden wrote:
> It is common for services to be stateless around their main event loop.
> If a process passes the EPOLL_KILLME flag to epoll_wait5() then it
> signals to the kernel that epoll_wait5() may not complete, and the kernel
> may send
It is common for services to be stateless around their main event loop.
If a process passes the EPOLL_KILLME flag to epoll_wait5() then it
signals to the kernel that epoll_wait5() may not complete, and the kernel
may send SIGKILL if resources get tight.
See my systemd patch:
It is common for services to be stateless around their main event loop.
If a process passes the EPOLL_KILLME flag to epoll_wait5() then it
signals to the kernel that epoll_wait5() may not complete, and the kernel
may send SIGKILL if resources get tight.
See my systemd patch:
18 matches
Mail list logo
