Date: Fri, 29 Jun 2001 04:20:51 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: Chris Costello <chris@calldei.com> Cc: freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r locking... why? Message-ID: <Pine.LNX.4.20.0106290356480.3220-100000@www.everquick.net> In-Reply-To: <20010628212856.E55395@holly.calldei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Thu, 28 Jun 2001 21:28:56 -0500 > From: Chris Costello <chris@calldei.com> > > > 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 <blacklist@brics.com> 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 <blacklist@brics.com>, or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.0106290356480.3220-100000>