O GNU / Linux conta processos e threads juntos quando limite seu número?

Quero limitar o número de processos por usuário na minha máquina, com /etc/security/limits.confe o valor nproc.

Eu li aqui que o Linux não faz distinção entre processos e threads?

Meu limite de nproc atual por usuário é 1024, mas se isso incluir também threads, é muito baixo no meu ponto de vista. A página de manual limits.confmenciona apenas "processo" para nproc e nada mais.

// edit // código de exemplo em C ++ com Boost // g ++ -o boost_thread boost_thread.cpp -lboost_thread

#include <unistd.h>
#include <iostream>
#include <boost/thread.hpp>
using namespace std;

int counter;

void print_thread(int i) {
    counter++;
    cout << "thread(" << i << ") counter " << counter << "\n";
    sleep(5);
    counter--;
}

int main() {
    int i = 0;
    int max = 1000000;

    while (i < max) {
        boost::thread(print_thread, i);
        i++;
    }

    return 0;
}

teste (removeu algumas linhas):

$ ulimit -u
1024
$ ./thread 
...
...
...
thread(828) counter 828
thread(829) counter 829
thread(830) counter 830
thread(831) counter 831
thread(832) counter 832
thread(610) counter thread(833833) counter 834

thread(834) counter 835
thread(835) counter 836
thread(836) counter 837
thread(837) counter 838
thread(838) counter 839
thread(839) counter 840
thread(840) counter 841
thread(841) counter 842
thread(842) counter 843
thread(843) counter 844
thread(844) counter 845
thread(845) counter 846
thread(846) counter 847
thread(847) counter 848
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >'
  what():  boost::thread_resource_error
Aborted (core dumped)

Meu laptop usa ~ 130 processos enquanto está ocioso. Portanto , o nproc , ou Linux em uma visão mais ampla, não distingue entre processos e threads. O que me parece razoável, porque os threads também podem ser cansativos, não apenas processos.

O nproclimite que você está falando se aplica a entidades executáveis , limitando, portanto, os threads (e, portanto, os processos que os contêm) . Todo processo possui pelo menos um thread (o thread principal), para que apenas os threads possam ser executados . A rigor, os processos não são "executáveis".

Esta resposta explica a diferença real entre threads e processos no Linux.

Testei o código na resposta de daya (também adicionada sleep(1);no código do thread) e, ao contrário dele (?!), Atingi o limite quando muitos threads foram criados: pthread_create()estava retornando EAGAIN. A pthread_create(3)documentação diz o seguinte sobre esse erro:

EAGAIN

Recursos insuficientes para criar outro encadeamento ou um limite imposto pelo sistema ao número de encadeamentos foi encontrado. O último caso pode ocorrer de duas maneiras: o limite de recursos flexíveis RLIMIT_NPROC (definido via setrlimit (2)), que limita o número de processos para um ID de usuário real, foi atingido; ou o limite de todo o sistema do kernel no número de threads, / proc / sys / kernel / threads-max, foi atingido.

Não vejo menção de um limite específico por thread no código-fonte do kernel ; vejo apenas RLIMIT_NPROClá, qual é o limite no qual você pode alterar limits.conf(com nproc) ulimit -uou setrlimit(2).

ulimit limita apenas o número de processos. Portanto, um valor definido usando

ulimit -u 1024

limitará o número de processos.

eg.

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

void* test(void *ptr){
   return 0;
}



int main()
{
        pthread_t thread[50];
        int i=0;

      for(i=0;i<50;i++){
      if(!pthread_create( &thread[i], NULL,test,NULL))
         printf("%d ",i);

       }


      for(i=0;i<50;i++)
       pthread_join( thread[i], NULL);
       return 0;
}

definir ulimit e verificar

lab@x:/tmp$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
lab@x:/tmp$ 
lab@x:/tmp$ 
lab@x:~$ cd /home/x
lab@x:/home/x$ ./thread 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 lab@x:/home/x$ 
lab@x:/home/x$ 
lab@x:/home/x$ ulimit -u 10
lab@x:/home/x$ 

o limite do processo está definido como 10

lab@x:/home/x$ ./thread 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 lab@x:/home/x$ 
lab@x:/home/x$ 

aqui 50 threads podem ser criados.