Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Jul 1999 00:26:46 +0000 (GMT)
From:      Terry Lambert <>
To: (David Schwartz)
Cc:,, chat@FreeBSD.ORG
Subject:   Re: Known MMAP() race conditions ... ?
Message-ID:  <>
In-Reply-To: <000001becfe2$a63dd060$> from "David Schwartz" at Jul 16, 99 04:26:37 pm

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.

> > 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

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

> 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

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
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to
with "unsubscribe freebsd-chat" in the body of the message

Want to link to this message? Use this URL: <>