In article <[EMAIL PROTECTED]>, Daniel C. Sobral
<[EMAIL PROTECTED]> wrote:
> "Ronald F. Guilmette" wrote:
>
> > As I say, my understanding is that FreeBSD still doesn't have real
> > and/or complete thread support in the kernel. So if you have a
> > multi-threaded application and one thread blocks (e.g. on I/O)
> > then the whole thing is blocked.
[...]
> Not to dismiss FreeBSD's kernel problems, but that thing about
> blocking is absurdly untrue.
It is in fact partially true. If a thread blocks on disk I/O then
the whole process (all threads) blocks. That can be significant for
applications that are disk intensive. I believe it to be the most
significant bottleneck in current versions of CVSup, for example.
(CVSup doesn't use FreeBSD's threads library, but it uses Modula-3's
built-in threads package which is similar in design.)
Once our aio support is knocked into shape, it should be possible for
userland threads packages to use that in preference to select(). Then
threads could run while one or more others were blocked on disk I/O.
Of course kernel thread support may improve soon enough so that this
approach isn't necessary.
For CVSup I plan to experiment with using a small farm of disk I/O
subprocesses (processes, not threads), communicating with the master
process via shared memory and/or pipes. Without trying it, I can't
say for sure whether it will yield a net win or a net loss in speed.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc. Seattle, Washington USA
"No matter how cynical I get, I just can't keep up." -- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
