Date: Fri, 29 Jun 2001 05:10:39 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: Chris Costello <chris@calldei.com> Cc: freebsd-hackers@freebsd.org Subject: Re: libc_r locking... why? Message-ID: <Pine.LNX.4.20.0106290503360.3878-100000@www.everquick.net> In-Reply-To: <20010628233355.F55395@holly.calldei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(on -hackers only, as this post is beyond the -smp charter) > > 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... > > That's correct. It's implemented using setjmp/longjmp, and > storing stack pointers and the like in thread-specific data > structures. Ah, okay. Thanks. I use this approach, too, but not for threads; I relegate this type of architecture to state machines. I guess that cramming multiple threads into a single PID would be considered a state machine of sorts... Sounds like I need to just ignore libc_r and stick to syscalls and what I've been doing. I must note, however, that the "uthreads" source directory for libc_r provides a handy checklist of functions that might need a bit of TLC. :-) Thanks again, Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- 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?Pine.LNX.4.20.0106290503360.3878-100000>