linux-kernel - Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

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]

Date:	Mon, 26 Feb 2007 11:22:46 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
cc:	Ingo Molnar <mingo@...e.hu>, Ulrich Drepper <drepper@...hat.com>,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Zach Brown <zach.brown@...cle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

On Mon, 26 Feb 2007, Evgeniy Polyakov wrote:
> 
> I want to say, that read() consists of tons of events, but programmer
> needs only one - data is ready in requested buffer. Programmer might
> not even know what is the object behind provided file descriptor.
> One only wans data in the buffer.

You're not following the discussion.

First off, I already *told* you that "read()" is the absolute simplest 
case, and yes, we could make it an event if you also passed in the "which 
range of the file do we care about" information (we could consider it 
"f_pos", which the kernel already knows about, but that doesn't handle 
pread()/pwrite(), so it's not very good for many cases).

But that's not THE ISSUE.

The issue is that it's a horrible interface from a users standpoint.  
It's a lot better to program certain things as a thread. Why do you argue 
against that, when that is just obviously true.

There's a reason that people write code that is functional, rather than 
write code as a state machine.

We simply don't write code like

	for (;;) {
	switch (state) {
	case Open:
		fd = open();
		if (fd < 0)
			break;
		state = Stat;
	case Stat:
		if (fstat(fd, &stat) < 0)
			break;
		state = Read;
	case Read:
		count = read(fd, buf + pos, size - pos));
		if (count < 0)
			break;
		pos += count;
		if (!count || pos == size)
			state = Close;
		continue;
	case Close;
		if (close(fd) < 0)
			break;
		state = Done;
		return 0;
	}
	}
	/* Returning 1 means wait in the event loop .. */
	if (errno == EAGAIN || errno == EINTR)
		return 1;
	/* Else we had a real error */
	state = Error;
	return -1;

and instead we write it as

	fd = open(..)
	if (fd < 0)
		return -1;
	if (fstat(fd, &st)) < 0) {
		close(fd);
		return -1;
	}
	.. 

and if you cannot see the *reason* why people don't use event-based 
programming for everything, I don't see the point of continuing this 
discussion.

See? Stop blathering about how everything is an event. THAT'S NOT 
RELEVANT. I've told you a hundred times - they may be "logically 
equivalent", but that doesn't change ANYTHING. Event-based programming 
simply isn't suitable for 99% of all stuff, and for the 1% where it *is* 
suitable, it actually tends to be a very specific subset of the code that 
you actually use events for (ie accept and read/write on pure streams).

		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/