Date: Sun, 9 May 1999 16:17:30 -0700 (PDT) From: <kip@lyris.com> To: "Richard Seaman, Jr." <dick@tar.com> Cc: hackers@freeBSD.org Subject: Re: problems with recursion in libc_r Message-ID: <Pine.SOL.4.05.9905091600160.16701-100000@luna> In-Reply-To: <19990509091415.E6953@tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Should I actually think about changes to make, or should I simply hold off and let more experienced kernel hackers take care of the fixes? I have previously ported my application, a heavily multithreaded list server, to Linux and am/was totally unimpressed with its performance. The port exists primarily because Linux is such a popular platform. Linux has basically implemented threads as processes with shared memory and used SIGUSR1 and SIGUSR2 to control communication between them. Needless to say, for any application that uses more than a few threads this is not very fast. When I tried running lyris, the list server, on comparable hardware, on FreeBSD, the throughput was at least 20x that of lyris on Linux. The company I work for would actually like to use FreeBSD for doing list hosting. However, before I start making any modifications to FreeBSD I would like to know that the changes I make will actually be incorporated, so that I will not suffer the same fate as PAO, namely having to reincorporate my changes each new release. -Kip On Sun, 9 May 1999, Richard Seaman, Jr. wrote: > On Fri, May 07, 1999 at 07:50:33PM -0700, kip@lyris.com wrote: > > I am running FreeBSD 3.1 STABLE. There appears to be a problem with > > wrterror and wrtwarning from malloc/free when using threads because it > > calls _thread_fd_lock_ which in turn calls malloc etc. > > I have made a stopgap fix to the two functions, by having them return > > before calling write. I hope that someone else will have a more > > intelligent fix. > > A bit of hackery that might help would be to call _thread_fd_table_init() > for fd's 0 to 2 when libc_r starts up (ie. in _thread_init()) > > There is also a deeper issue, which is that libc (and libc_r) need > multpile versions of some syscalls, such as write(). There needs > to be the "pure syscall", which is libc is _write(), and in libc_r > is _thread_sys_write(). (Ultimately it would be nice if both libc > and libc_r used the same naming convention). Then there needs to > be something like _libc_write(), which is the version of write used > internally to libc (and libc_r). Then finally there needs to be > the version exported to user apps, write(). Maybe there even needs > to be more layers. GNU glibc has at least 4 layers, I think. > > The reason for the multiple layers is that more complex apps, like > threads libraries, end up needing to "wrap" the pure syscall to > implement things like fd locking (libc_r), or pthread_cancellation > points (libc and libc_r). It is not always correct to use the > final wrapped versions of the syscalls within libc or within > threads libraries themselves. > > Then, an internal libc function like malloc would call the appropriate > version of write() that didn't have the potential to recurse. > > > > > A partial trace follows: > > #0 malloc (size=76) at /usr/src/lib/libc_r/../libc/stdlib/malloc.c:1066 > > #1 0x82ee633 in _thread_fd_table_init (fd=2) at > > /usr/src/lib/libc_r/uthread/uthread_fd.c:75 > > #2 0x82eea9b in _thread_fd_lock (fd=2, lock_type=2, timeout=0x0) at > > /usr/src/lib/libc_r/uthread/uthread_fd.c:272 > > #3 0x82e9aa9 in write (fd=2, buf=0xefbfdc27, nbytes=5) at > > /usr/src/lib/libc_r/uthread/uthread_write.c:58 > > #4 0x830f370 in wrtwarning (p=0x8399c81 "recursive call.\n") at > > /usr/src/lib/libc_r/../libc/stdlib/malloc.c:292 > > #5 0x8310050 in malloc (size=76) at > > /usr/src/lib/libc_r/../libc/stdlib/malloc.c:1069 > > #6 0x82ee633 in _thread_fd_table_init (fd=2) at > > /usr/src/lib/libc_r/uthread/uthread_fd.c:75 > > #7 0x82eea9b in _thread_fd_lock (fd=2, lock_type=2, timeout=0x0) at > > /usr/src/lib/libc_r/uthread/uthread_fd.c:272 > > #8 0x82e9aa9 in write (fd=2, buf=0xefbfdc27, nbytes=5) at > > /usr/src/lib/libc_r/uthread/uthread_write.c:58 > > #9 0x830f370 in wrtwarning (p=0x8399b95 "junk pointer, too high to make > > sense.\n") at /usr/src/lib/libc_r/../libc/stdlib/malloc.c:292 > > #10 0x830ffb9 in ifree (ptr=0x863c0a0) at > > /usr/src/lib/libc_r/../libc/stdlib/malloc.c:1043 > > #11 0x8310151 in free (ptr=0x863c0a0) at > > /usr/src/lib/libc_r/../libc/stdlib/malloc.c:1097 > > #12 0x82e2df1 in __builtin_vec_delete (ptr=0x863c0a0) > > > > > > -Kip > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Richard Seaman, Jr. email: dick@tar.com > 5182 N. Maple Lane phone: 414-367-5450 > Chenequa WI 53058 fax: 414-367-5852 > > 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.SOL.4.05.9905091600160.16701-100000>