Date: Fri, 16 Jul 1999 16:26:37 -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: <000001becfe2$a63dd060$021d85d1@youwant.to> In-Reply-To: <199907162257.PAA16303@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. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001becfe2$a63dd060$021d85d1>