Date: Thu, 15 Jul 1999 11:54:35 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Terry Lambert" <tlambert@primenet.com> Cc: <Doug@gorean.org>, <scrappy@hub.org>, <beyssac@enst.fr>, <chat@FreeBSD.ORG> Subject: RE: Known MMAP() race conditions ... ? Message-ID: <001101becef3$7b5056b0$021d85d1@youwant.to> In-Reply-To: <199907151842.LAA29095@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On FreeBSD, I'm basically screwed. I'd have to write me own resolver > > library to do the job. Licensing problems prevent me from using > pretty much > > every nice resolver library out there. > > The bind 8.x stuff doesn't have licensing issues; it allows multiple > concurrent operations. It is merely that the 4.x resolved is wedged > into libc that causes your problem. The bind license has 'forced speech' requirement. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. > > > Completion ports are no more, and no less, than VMS AST's. Just > > > like aio* in FreeBSD, and much of the POSIX crap that's passing > > > for standards these days. Completion ports are not about asynchronous I/O. They're not about having your I/O routines called automatically. They're about having the optimimum number of threads running. What completion ports do is allow a group of threads to be associated such that if one thread blocks, another one is automatically freed. This way, on an N processor machine, you can nearly always have N active threads. This is extremely difficult to do well on pretty much every UNIX. > > > They may make it easier to code, by calling your callbacks, but > > > the idea that network buffers should be in user space instead of > > > on the kernel side of the protection domain barrier is just > > > plain nuts. I'm not really sure why you feel that way. If there weren't performance issues, I don't see why you wouldn't want the whole network stack to be in user space. > > They're on both sides in every implementation. It's just a > matter of when > > the borders get crossed. > > I disagree. I can turn around reads and writes in the kernel without > taking the copy overhead. NFS does this, and a KLD that could do this > for SAMBA and AFS, while not trivial, given the state of the FreeBSD > VFS interface, the protocol stack incursions for routing of the > specific packets, and the mbuf reference to buffer cache objects that > would be required, is well within the realm of possibility. If > anything, the ability to use the GPL'ed SAMBA code in the Linux > kernel may well be the deciding factor for eventual FreeBSD vs. > Linux SMB performance, the same as it was for Linux vs. FreeBSD NFS > performance. That is true. But it's really not relevant to the current discussion. But I still think it's better to pull everything into user space to avoid copies rather than push everything into kernel space. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001101becef3$7b5056b0$021d85d1>