Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Apr 2000 17:07:00 -0500
From:      Chris Costello <chris@calldei.com>
To:        Brian O'Shea <boshea@ricochet.net>
Cc:        Daniel Eischen <eischen@vigrid.com>, Jason Evans <jasone@canonware.com>, A G F Keahan <ak@freenet.co.uk>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Multithreaded server performance
Message-ID:  <20000424170700.A14783@holly.calldei.com>
In-Reply-To: <20000424141957.W337@beastie.localdomain>
References:  <20000424010315.U337@beastie.localdomain> <Pine.SUN.3.91.1000424061006.7393A-100000@pcnet1.pcnet.com> <20000424141957.W337@beastie.localdomain>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, April 24, 2000, Brian O'Shea wrote:
> On Mon, Apr 24, 2000 at 06:13:53AM -0400, Daniel Eischen wrote:
> > On Mon, 24 Apr 2000, Brian O'Shea wrote:
> > > 
> > > I was under the impression that, because user thread scheduling is done
> > > in user mode, a thread that goes to sleep calling a blocking read()
> > > system call will put the entire process to sleep until that read()
> > > returns (and so all user threads in the process will also be blocked).
> > > Is this correct?
> > 
> > 1. You are mistaken.
> 
> Could you elaborate?  The text that I am using [1] warns about blocking
> system calls putting the process (and thus all user threads) to sleep.
> This book has no FreeBSD specific information, so anything specific to
> FreeBSD would be really interesting to hear.

   FreeBSD's threads implement has its own read() function which
will make a non-blocking read() call (using the _real_ syscall)
for the specified amount of bytes.  Now a non-blocking read()
call fails unless all the data in nbytes can be read into buf.
So our implementation will continue to do a non-blocking read
until all the data can be copied and then allows the thread
continue, thus blocking only the calling thread.

   At least that's what the source code tells me.

-- 
|Chris Costello <chris@calldei.com>
|I smell a wumpus.
`----------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




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