GNU / Linux compte-t-il les processus et les threads ensemble lorsque je limite leur nombre?

Je souhaite limiter le nombre de processus par utilisateur sur ma machine, avec /etc/security/limits.confet la valeur nproc.

J'ai lu ici que Linux ne fait pas de distinction entre les processus et les threads?

Ma limite de nproc actuelle par utilisateur est de 1024, mais si cela inclut également les threads, elle est trop faible à mon avis. La page de manuel de limits.confne mentionne que "process" pour nproc et rien d'autre.

// modifier // exemple de code en C ++ avec 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;
}

test (supprimé quelques lignes):

$ 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)

Mon ordinateur portable utilise environ 130 processus tout en étant inactif. Donc, nproc , ou Linux dans une vue plus large, ne fait pas de distinction entre les processus et les threads. Ce qui me semble raisonnable, car les threads pourraient aussi épuiser, pas seulement les processus.

La nproclimite dont vous parlez s'applique aux entités exécutables , elle limite donc les threads (et donc les processus les contenant) . Chaque processus a au moins un thread (le thread principal), de sorte que seuls les threads peuvent être exécutés . À strictement parler, les processus ne sont pas "exécutables".

Cette réponse explique la vraie différence entre les threads et les processus sous Linux.

J'ai testé le code dans la réponse de daya (également ajouté sleep(1);dans le code de thread) et contrairement à lui (?!), J'ai atteint la limite quand trop de threads ont été créés: pthread_create()revenait EAGAIN. La pthread_create(3)documentation indique ce qui suit à propos de cette erreur:

Encore une fois

Ressources insuffisantes pour créer un autre thread, ou une limite imposée par le système sur le nombre de threads a été rencontrée. Ce dernier cas peut se produire de deux manières: la limite de ressources logicielles RLIMIT_NPROC (définie via setrlimit (2)), qui limite le nombre de processus pour un ID utilisateur réel, a été atteinte; ou la limite à l'échelle du système du nombre de threads, / proc / sys / kernel / threads-max, a été atteinte.

Je ne vois aucune mention d'une limite spécifique par thread dans la source du noyau , je ne vois que RLIMIT_NPROClà, qui est la limite dans laquelle vous pouvez changer limits.conf(avec nproc), ulimit -uou setrlimit(2).

ulimit limite le nombre de processus uniquement. Par conséquent, un ensemble de valeurs utilisant

ulimit -u 1024

limitera le nombre de processus.

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;
}

définir ulimit et vérifier

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$ 

la limite de processus est fixée à 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$ 

ici 50 threads peuvent être créés.