Damian Morris <[EMAIL PROTECTED]> writes:
> On a 2.4 kernel, a combination of ulimit and
> /proc/sys/kernel/threads-max is your limit for "regular"
> processes. For threads, additional limitations may be imposed by:
>
> - the JVM. Prior to 1.3, the Sun JVM's assumed a 2MB stack, imposing
> a hard limit of 1024 threads.
>
> - your threads implementation. From the top of my head, prior to
> around 0.7, LinuxThreads also hard-coded a 2MB stack for threads
This is still true for Debian's x86 libpthread. In order to get
floating stacks glibc has to be built with --enable-kernel=2.4.0 (or
higher) and for i686. IIRC Debian's glibc gets built for i386 and
--enable-kernel=2.0.30.[1]
Also glibc, by default, gets built with PTHREAD_THREADS_MAX == 1024.
In any case, it isn't a good idea to use that many threads. With J2SE
<1.4 it was inevitable in some cases, but J2SE >= 1.4 has non-blocking
multiplexing IO so you don't need a thread for each connection
anymore.
Juergen
Footnotes:
[1] There just was a thread about "CPU-optimized" builds on
debian-devel and all they talked about was performance. But
compiling for newer CPUs also can provide non-performance related
benefits: E.g. compiling glibc for i686 gives you floating
stacks and high precision timing.
--
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux.html
Run Java 2 SE v1.3.1 on your iPAQ:
http://www.handhelds.org/pipermail/ipaq/2001-June/007221.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
