Date: Fri, 16 Jul 1999 17:36:14 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Terry Lambert" <tlambert@primenet.com> Cc: <unknown@riverstyx.net>, <chat@FreeBSD.ORG> Subject: RE: Known MMAP() race conditions ... ? Message-ID: <000101becfec$605cd280$021d85d1@youwant.to> In-Reply-To: <199907170026.RAA19207@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > FreeBSD's user space threads implementation uses call conversion > > > to wrap system calls. > > > > Some system calls. > > Which ones? What you are saying is tantatmount claiming that libc_r > is incomplete. Identify the problems that you are having, and they > will be fixed. > > Just saying "it's broke" is worse than useless. I was under the impression that disk I/O was still blocking in FreeBSD's libc_r. I was also under the impression that the resolver was blocking. If disk I/O really is non-blocking, I would expect the performance to suffer because thread context switches in a user-space threads implementation are generally more expensive than a kernel thread blocking on I/O. User-space threads are not inherently bad, they just have different tradeoffs than kernel threads. > Yes. The NFS code can return "EWOULDBLOCK", if the operation would > block. But does libc_r do this? As I see it, there are two answers, and both are at least somewhat bad: 1) Yes. Which means that a significant fraction of disk I/O will require extra user-space thread context switches. 2) No. Which means that slow I/O will stall all the threads. > > Umm, huh? Reading from an NFS server is buggy? Reading from a > slow disk is > > buggy? > > No. Both cases should result in an EWOULDBLOCK and a threads context > switch, pending the data being present to be read, since non-blocking > I/O is being substituted. Which means unneccesary context switches, when simply waiting would be better. The problem is, if you want to avoid the occasional long delay, you have to accept extra context switches all the time. Not necessarily the worst thing in the world, but it's a tradeoff. > > I see them all the time. 'gethostbyname' is a good example. > > Are you forcing the use of TCP for this? This results in a spin > loop. > > Please obtain and compile the libresolver from bind 8.x, which is > reentrant, and link it before you link libc_r. I am calling 'gethostbyname'. Is that wrong? Bind's license, unfortunately, prohibits me from linking to it. Once I wrote my own resolver library, this problem goes away. But not everyone can spend the time to do that to optimize for a platform. > > NFS reads are too. > > A slow server should be no problem. The read call, in the case > of non-blocking I/O, checks for the presence of a local backing > page, and if it is not present, schedules a fault-in of the page > (the real read), and returns "EWOULDBLOCK". > > If you are saying this does not work, then it is a bug that > needs to be addressed. I believe Matt Dillon is currently > hacking in the NFS code, and could address this in almost no > time, given his familiarity with the VM system. That's not what I'm saying. I'm saying it's a painful tradeoff. What you want is a thread to block if the I/O takes too long. You don't have that choice. > > Any problem can be fixed ten ways. The thing is, if code > > that runs fine everywhere else breaks on FreeBSD, you have to > > start suspecting that it's the OS. The point of this is not > > "FreeBSD's threads is bad", it's not that bad. It's just not up > > to some real world applications. And for those, another OS might > > be a better choice. > > If it's "not that bad", then it won't take 10 years to fix. Yes, I've been waiting for fixes in FreeBSD's threads implementation for more than a year now. The vast majority of them have taken place, and I'm fairly happy with the current state of FreeBSD's threads support. However, it is really not as good as the threads support on many other operating systems, including NT. If you need stellar threads support, FreeBSD is not the operating system you probably want to use. At the current rate of progress though, this could change in a few months. 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?000101becfec$605cd280$021d85d1>