From owner-freebsd-hackers Thu Jun 28 21:21: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 5ED0E37B409; Thu, 28 Jun 2001 21:20:55 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f5T4Kqw03424; Fri, 29 Jun 2001 04:20:52 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Fri, 29 Jun 2001 04:20:51 +0000 (GMT) From: "E.B. Dreger" To: Chris Costello Cc: freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r locking... why? In-Reply-To: <20010628212856.E55395@holly.calldei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Date: Thu, 28 Jun 2001 21:28:56 -0500 > From: Chris Costello > > > Please pardon the cross-posting; I'd rather keep responses on whichever > > list is more appropriate. > > 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. So it's a thunk/kludge not only to enforce "proper" behavior, but also to prevent the process from blocking and stalling other threads? This makes sense. > 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. The reason that I asked is because I'm writing a program that uses rfork() in the same manner as the new rfork_thread(). I couldn't understand the need to wrap kevent(2), bind(2), or accept(2)... In my mind, I was thinking "data integrity", trying to prevent processes in the same "thread family" from stepping on one another. Blocking is not a problem; where I can't use non-blocking calls, I use a worker thread. I guess that I was looking at man pages and bits of libc_r code without understanding the pthread implementation. I knew that it was userland, but I thought that it created multiple processes... if this is not the case, then I was apparently comparing apples to mangoes. Am I correct that libc_r does _not_ use multiple processes to create threads? Grepping for "fork" in *.c files under /usr/src/lib/libc_r leads me to believe that this is so... ...I think that, with your prompting, I've answered my question. Thanks, Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to , or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message