[lkml]   [1998]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thread implementations...

On Sun, 28 Jun 1998, Linus Torvalds wrote:

> The same is not true of any of the other cases for copying from one
> source to another. Yes, I can imagine doing insanely clever things like
> just copying skb's around from one socket to another, but it's by no
> means obvious how to do it, nor whether it is a feature that I'd be
> ready to support forever even if I had a initial implementation.

i think all these copyfd() variations are pretty robust regarding the
future, as they represent some kind of caching architecture, but on a much
higher scale. For example, an fd->socket operation is a 'writeback'. A
socket->socket transfer is a 'writethrough', a socket->fd is a 'cache
fill' operation. So whatever higher level caching scheme (obviously with
multiple hosts) we will have, these basic operations will likely to
survive. (or die a big death together with all the other related concepts)

the caches in question are the VM (memory containing information on which
user-defined CPU routines can operate), kernel memory (central information
container), disk(s) (mass persistant information container), and other
hosts (complex but distant, information-producing entities) connected by
some interface(s). The whole point being that this host should act as a
complex information-producing entity too.

[sorry if the formulation is a bit extreme, but i wanted to avoid quickly
outdated terms :)] These caches and basic operations between them are i
think not likely to go away anytime soon. And fds act as simple IO-channel

in short: sendfile() is cool.

-- mingo

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.062 / U:0.680 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site