Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?000001becfe2$a63dd060$021d85d1>