From owner-freebsd-chat Fri Jul 16 17:27: 3 1999 Delivered-To: freebsd-chat@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id A985114C2B for ; Fri, 16 Jul 1999 17:26:58 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA02542; Fri, 16 Jul 1999 17:26:56 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd002515; Fri Jul 16 17:26:47 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA19207; Fri, 16 Jul 1999 17:26:46 -0700 (MST) From: Terry Lambert Message-Id: <199907170026.RAA19207@usr05.primenet.com> Subject: Re: Known MMAP() race conditions ... ? To: davids@webmaster.com (David Schwartz) Date: Sat, 17 Jul 1999 00:26:46 +0000 (GMT) Cc: tlambert@primenet.com, unknown@riverstyx.net, chat@FreeBSD.ORG In-Reply-To: <000001becfe2$a63dd060$021d85d1@youwant.to> from "David Schwartz" at Jul 16, 99 04:26:37 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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. > > As a result, "blocking" system calls do not block other threads. In > > point of fact, a "blocking" call made by a thread will result in a > > user space threads scheduler entry, which will result in that thread > > being suspended until the blocking call can be completed without > > blocking. > > Is this true for a read of a file mounted from a slow NFS server? Yes. The NFS code can return "EWOULDBLOCK", if the operation would block. If the NFS server is merely slow, then using non-blocking I/O will cause the data to be prefetched, and the read can be retried. The user space threads implementation in FreeBSD uses non-blocking I/O as the main mechanism for implementing call conversion of blocking calls to non-blocking calls with a context switch forced on an EWOULDBLOCK result. > 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. > > rather than a call conversion, please provide a test case, > > and it will be fixed. > > > > I have had no problems running LDAP, ACAP, and other well-written > > pthreads using code on FreeBSD, without seeing the problems you > > are claiming to see. > > 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. > 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. > > Let me know when/if you can provide any test cases, and I will > > be happy to help diagnose the actual source of the problem. > > 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message