Date: Thu, 28 Jun 2001 21:28:56 -0500 From: Chris Costello <chris@calldei.com> To: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> Cc: freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r locking... why? Message-ID: <20010628212856.E55395@holly.calldei.com> In-Reply-To: <Pine.LNX.4.20.0106290112060.1425-100000@www.everquick.net>; from eddy%2Bpublic%2Bspam@noc.everquick.net on Fri, Jun 29, 2001 at 02:15:04AM %2B0000 References: <Pine.LNX.4.20.0106290112060.1425-100000@www.everquick.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, June 29, 2001, E.B. Dreger wrote: > Please pardon the cross-posting; I'd rather keep responses on whichever > list is more appropriate. > > Why are bind(2), accept(2), kevent(2), etc. wrapped in libc_r? Currently, the pthreads implementation is done entirely in userland. This means that a syscall which would normally block needs to have code in it to check if it would block (write(2) is a really simple example of this), and if it would, schedule another thread (cancelling, or blocking, the calling thread) to run, and eventually get back to the thread which is blocking on write, check for/read more data, cancel again, etc., until the requested amount of data has been read or an error occurs. This example, of course, applies to instances where write() is called on a file descriptor which does _NOT_ have O_NONBLOCK set. kevent(2), bind(2), accept(2) etc. all do the same thing for the same reasons. -- +-------------------+-----------------------------------------+ | Chris Costello | Advanced design: | | chris@calldei.com | Upper management doesn't understand it. | +-------------------+-----------------------------------------+ 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?20010628212856.E55395>