linux-kernel - Re: [PATCH] rfc: threaded epoll

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: <alpine.LFD.0.98.0705072132580.3974@woody.linux-foundation.org>
Date:	Mon, 7 May 2007 21:35:39 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ulrich Drepper <drepper@...il.com>
cc:	Davide Libenzi <davidel@...ilserver.org>,
	Davi Arnaut <davi@...ent.com.br>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rfc: threaded epoll_wait thundering herd

On Mon, 7 May 2007, Ulrich Drepper wrote:
> 
> This is absolutely not comparable.  When read/write is canceled no
> data is lost.  Some other thread might have to pick up the slack but
> that's it.

That's bullsh*t, Uli, and you know it.

Whatever the thread read() into it's buffer is effectively gone. You don't 
know how much of the buffer was updated, so other threads cannot use the 
data.

In fact, the exact *reverse* of what you claim is true. With "poll()" or 
"select()", other threads *can* actually look at the result buffer, since 
it has a known size and format that is independent of the return value, 
unlike read().

But the real issue is that if you start cancellign threads without any 
other synchronization, you are going to lose data anyway. Claiming 
anything else is just silly. The whole scenario you talk about is 
nonsensical, never mind that read() actually handles it *less* well rather 
than better as you claim.

		Linus
-
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/