linux-kernel - Re: [patch 14/22] pollfs: pollable futex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a36005b50705020108o6fb7495ak2383ae64e49c48a0@mail.gmail.com>
Date:	Wed, 2 May 2007 01:08:26 -0700
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Eric Dumazet" <dada1@...mosbay.com>
Cc:	"Davi Arnaut" <davi@...ent.com.br>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Davide Libenzi" <davidel@...ilserver.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 14/22] pollfs: pollable futex

On 5/2/07, Eric Dumazet <dada1@...mosbay.com> wrote:
> Well, poll() level edge semantic is well defined, you cannot cheat or change it.
>
> If many threads call poll() on the same end point, they should *all* return POLLIN/whatever status.

This means to me it's the wrong abstraction for this.  We had a nice
solution for this with Evgeniy's kevent interfaces.  It worked without
forcing futexes is this inflexible poll() interface.

> This is why programs usually use one thread to dispatch events to workers, or at least dont queue XXXX threads calling poll() on one fd.

No.  This is why programs are forced to waste cycles by doing this.
Ideally this would not happen.  Ideally you'd park all worker thread
in the same place and have them woken up one by one.  Again, Evgeniy's
code was able to do this.  This approach seems to be a big step
backward.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/