Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Jul 1999 00:26:46 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        davids@webmaster.com (David Schwartz)
Cc:        tlambert@primenet.com, unknown@riverstyx.net, chat@FreeBSD.ORG
Subject:   Re: Known MMAP() race conditions ... ?
Message-ID:  <199907170026.RAA19207@usr05.primenet.com>
In-Reply-To: <000001becfe2$a63dd060$021d85d1@youwant.to> 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
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907170026.RAA19207>