From owner-freebsd-chat Fri Jul 16 16:28: 2 1999 Delivered-To: freebsd-chat@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 019F314CAE for ; Fri, 16 Jul 1999 16:28:00 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Fri, 16 Jul 1999 16:26:37 -0700 From: "David Schwartz" To: "Terry Lambert" Cc: , Subject: RE: Known MMAP() race conditions ... ? Date: Fri, 16 Jul 1999 16:26:37 -0700 Message-ID: <000001becfe2$a63dd060$021d85d1@youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <199907162257.PAA16303@usr05.primenet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 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. > 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? > If you are talking about non-system call interfaces that sit in spin > loops (e.g. library calls), then you are talking about something else > being the source of your problem (i.e. it's not FreeBSD's fault that > the code does not work, it's the code's fault). No, I think it was quite clear what I was talking about. > In other words: > > Q: "Why does FreeBSD block a whole process if one thread blocks?" > > A: "Because the code that is blocking is buggy." Umm, huh? Reading from an NFS server is buggy? Reading from a slow disk is buggy? > 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. NFS reads are too. > 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. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message