Date: Mon, 01 May 2000 14:17:03 -0600 From: Warner Losh <imp@village.org> To: boshea@ricochet.net Cc: Jason Evans <jasone@canonware.com>, A G F Keahan <ak@freenet.co.uk>, freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <200005012017.OAA18640@harmony.village.org> In-Reply-To: Your message of "Mon, 24 Apr 2000 01:03:15 PDT." <20000424010315.U337@beastie.localdomain> References: <20000424010315.U337@beastie.localdomain> <3903AEA6.FA7CBBAB@freenet.co.uk> <20000423212115.E31925@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000424010315.U337@beastie.localdomain> "Brian O'Shea" writes: : 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? No. the pthreads wrappers only make you think that you are calling read, when in fact it multiplexes things behind the scenes for you. If one thread is reading, then another thread can be running. All this assumes that drivers implement select/poll correctly and nonblocking I/O is supported as well. Really a slick setup for when you need to do lots of threading, a big pain when you don't due to locking issues that come up when you trie to dice things into too many threads. But I digress. Warner 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?200005012017.OAA18640>