Re

В LinuxThreads - 8192.

странно, а почему тогда у меня не создается более 256 тредов

EAGAIN? Ну значит других каких-то ресурсов не хватает....

> как можно обойти это ограничение ?

glibc пересобрать ?
У меня раньше такое ограничение, если не ошибаюсь, в RH 7.* было

Что бы увеличить, попробуй на них делать pthread_detach().

Re:

>glibc пересобрать ?
Ага. В LinuxThreads максимум 1024.

> Ага. В LinuxThreads максимум 1024.

Откуда такая цифра ? Вот например, что в ChangeLog'е сказанно:

2002-08-08 Jakub Jelinek <jakub@redhat.com>

* sysdeps/unix/sysv/linux/bits/local_lim.h (PTHREAD_THREADS_MAX):
Bump to 16384.

А вот это из FAQ по LInuxThreads:

.10: My application needs to create thousands of threads, or maybe even more. Can I do this with LinuxThreads?
No. You're going to run into several hard limits:

* Each thread, from the kernel's standpoint, is one process. Stock Linux kernels are limited to at most 512 processes for the super-user, and half this number for regular users. This can be changed by changing NR_TASKS in include/linux/tasks.h and recompiling the kernel. On the x86 processors at least, architectural constraints seem to limit NR_TASKS to 4090 at most.
* LinuxThreads contains a table of all active threads. This table has room for 1024 threads at most. To increase this limit, you must change PTHREAD_THREADS_MAX in the LinuxThreads sources and recompile.
* By default, each thread reserves 2M of virtual memory space for its stack. This space is just reserved; actual memory is allocated for the stack on demand. But still, on a 32-bit processor, the total virtual memory space available for the stacks is on the order of 1G, meaning that more than 500 threads will have a hard time fitting in. You can overcome this limitation by moving to a 64-bit platform, or by allocating smaller stacks yourself using the setstackaddr attribute.
* Finally, the Linux kernel contains many algorithms that run in time proportional to the number of process table entries. Increasing this number drastically will slow down the kernel operations noticeably.

(Other POSIX threads libraries have similar limitations, by the way.) For all those reasons, you'd better restructure your application so that it doesn't need more than, say, 100 threads. For instance, in the case of a multithreaded server, instead of creating a new thread for each connection, maintain a fixed-size pool of worker threads that pick incoming connection requests from a queue.

ПС
но у меня всеравно максимум 1535, непонятно почему

Re:

anonymous:

В твоей же цитате:

"* LinuxThreads contains a table of all active threads. This table has room for 1024 threads at most. To increase this limit, you must change PTHREAD_THREADS_MAX in the LinuxThreads sources and recompile."

Обычно это и является минимальным порогом числа нитей (при определенной конфигурации PAM порог может быть ниже - RLIMIT_NPROC).

Если у тебя число нитей может превосходить 1024, то у тебя не LinuxThreads (ну или по меньшей мере неоригинальный или не очень старый LinuxThreads).

А в чем проявляется то, что нельзя создавать новые нити?
Попробуй запустить что-нибудь вроде ltrace -S на простое приложение, плодящее нити.

Надо пересобрать ядро с опцией соответствующейт (не знаю точного названия). У Стивенса так написано.

glibc и linuxthreads у меня из дестрибутива. Это 2.3.2. Я
когда-то давно пересобирал но это ни к чему не привело, щас
даже неприпомню как.

Так же в дестрибутиве моем PAM'а нет.

RLIMIT_NPROC - unlimited.
RLIMIT_STACK - тоже

Странно то что:

/usr/include/bits/local_lim.h:#define PTHREAD_THREADS_MAX 16384

причем если запрашивать от рута то доходит до:
1531
если от обычного пользователя:
1236

ltrace - ничего толком не говорит и очень быстро вываливается

pthread_create(0x08049164, 0, 0x0804846c, 0, 0x40281d24 <unfinished ...>
SYS_rt_sigprocmask(2, 0, 0xbffff7c4, 8, 2) = 0
SYS_write(4, 0xbffff7b0, 148, 0x4002f074, 0xbffff7b0) = 148
SYS_rt_sigprocmask(2, 0, 0xbffff6f0, 8, 2) = 0
SYS_rt_sigsuspend(0xbffff6f0, 8, 0x40281d24, 4, 0x40284980) = -4
--- SIGINT (Interrupt) ---
+++ killed by SIGINT +++

чего вдруг ? Правда у меня там sleep(10), может он так на него
влияет, хез...

perror - Interrupted system call

Что можно предположить в таком ракурсе ?

спасибо за комментарии. все больше и больше убеждаюсь, что пора отказываться от тредов в пользу форк+общая память. задавал RLIMIT_NPROC в помощью setrlimit тоже не помогает. сколько же проблем с этими трредами, и чтоб их решить надо что-то пересобирать :-(

> все больше и больше убеждаюсь, что пора отказываться от тредов в пользу форк+общая память

ага, вот что я еще нашел:

The maximum number of pthreads per user is 1024. This is set in the pthread
libraries. The maximum number of pthreads for the entire system can be set
in proc, but it's unlikely you'd need to change this value.

The way they seem to get that number is that pthread's stack space is
allocated on the heap and each thread takes 2 megs of heap by default.
Linux has a maximum of 2 gig heap per user, so 2meg @ 1024 give you 2 gigs
of heap.

If you need to increase the maximum number of threads per user, you'll need
to recompile the pthread library and decrease the amount of heap per thread.
This could have system wide effects, so I don't recommend it except for
finely tuned application servers. It's better to re-architect your software
around it or move to a different environment.