On Tuesday 22 March 2005 00:47, Timothy Miller wrote: > The approach is right; we just don't want the copy overhead of what > you're calling a 'socket', which really it isn't. You're referring > to read/write calls to a character or block device. And that's OKAY, > except for the necessary copies.
No, I'm talking about sockets. I use them all the time in my cluster storage work, for high performance synchronization. Somehow, you've gotten an inaccurate picture of the overhead involved. It's miniscule. The overhead of the copy to/from user is dwarved by other things, like the context switch when we go to sleep. You also need to think about the amount of data that will be going over this socket, that's miniscule too. It's just a few bytes for every indirect buffer submission, whereas the indirect buffer may be a megabyte if we like. I really feel the socket is the right tool for the job, and that blocking on an ioctl is, as I said, crude. And I meant in comparison to socket-style synchronization, not busy waiting, which I would refer to as "wretchedly, unacceptably, disgustingly crude". Sockets let you do two-way streaming message-based synchronization, which is precisely what we want. Think of two ring buffers, one to send requests and one to receive events. That is what a socket is, except it also has some very, nice efficient process synchronization grafted onto it. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
