On Sun, Aug 31, 2003 at 11:00:52AM +0900, GOTO Masanori wrote: > At 30 Aug 2003 19:27:36 +0100, > Philip Blundell wrote: > > > > On Sat, 2003-08-30 at 17:45, GOTO Masanori wrote: > > > I wonder it's really safe. If we create a lot of threads like Java > > > EJB environment, we consume virtual memory four times faster than the > > > current implementation. You find STACK_SIZE is a boundary for each > > > thread. The right way is to support floating stack (thus libc6-686) > > > or nptl + tls, I think. I'm afraid this patch affects badly. > > > > Ah. Does Java really create that many threads? > > Yes, especially enterprise Java environment creates more than 100 > threads at the same time. Could you drop this patch? > > At Sat, 30 Aug 2003 17:30:13 -0400, > Daniel Jacobowitz wrote: > > On Sat, Aug 30, 2003 at 08:02:05PM +0100, Philip Blundell wrote: > > > On Sat, 2003-08-30 at 18:50, Daniel Jacobowitz wrote: > > > > Or get back to having an i686 libc... this is one of the major > > > > advantages. > > > > > > Yes, indeed. Did we ever manage to find a way to make upgrades safe > > > with this? I guess we could ship both the i386 and i686 versions in the > > > same package, which would avoid any problems at the risk of angering > > > non-i686 users. > > > > I think that would be safe. I also think it's a good idea. Doesn't > > dpkg have a filter-directories feature, or did that never happen? Hmm, > > looks like it never happened. > > > > If we had versioned provides, we could do it that way instead... > > Yes, I agree. Only concern is where do we put ld-linux.so.2 - > /lib/ld-linux.so.2 (i386) and /lib/i686/ld-linux.so.2 (i686) ?
RH doesn't even bother with an i686 version of ld-linux.so.2. Just libc, libm, libpthread, librt. > BTW, the big problem is that application using linuxthreads gets > sigsegv when I use glibc which compiled with -march=i686 option. This > is the reason why I have not introduced libc6-i686 for a long time. > It breaks after issuing modify_ldt instruction. I guess Redhat patch > has some workaround modifications, or it's toolchain issue. It needs > more investigations for supporting i686 libc6, tls, and nptl. Do you have a patch to build these libraries from the debian source? If you'll post one to debian-glibc I'll investigate it. I use an i686 glibc built from similar sources all the time without trouble. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
