1. Есть класс 
2. Есть внешняя ф-ия по отношению классу, но объявленная как friend


Внутри класса создаю поток и в качестве параметра передаю ему ту самую внешнюю фию и сам экземпляр класса.

Я в потоке улаляю переданный экземпляр класса и вродебы все нормально удаляется, ао крайнй мере управление передается в деструктор.

На первый взгляд кажется все чинно, но вот попробовла подряд создать около 300 таких класов с потоками и вдруг мне Linux начал говорить что ему нехватает памяти на создание потока ?

С чего бы это, ведь вроде потоки создаются и удаляются нормально, а памяти говорит не хватает.

Artemon, ну ты понял, код давай сюда 

Artemon, у тебя потоки NPTL или старые линуксовые?

Artemon, 
давай сюда код

в плане использования памяти разницы нет

MAKCim, разве? я читал, что NPTL отличается тем, что не выполняется копирование страниц памяти процесса - значит память выделяется... Видимо, что-то не то читал...

любой процесс в Linux, созданный с помощью clone() с указанием флага CLONE_VM, получает в "наследство" адресное пространство родителя
и LT, и NPTL реализованы с помощью clone() + CLONE_VM
другое дело, что NPTL использует для создания потока еще и CLONE_THREAD, который специально ввели для эффективной имплементации POSIX-потоков
CLONE_THREAD включает в себя следующие нововведения:
1. Группы потоков (TGID, TID)
2. Изменение семантики exec*, exit, работы сигналов
(вообще там много всего, но это основное)

MAKCim, спасибо, буду знать.

А сам поток при этом завершается? pthread_join вызывали или detached статус потоку ставили?


Память - да, а вот собственно потоки - неизвестно 


Это сообщение отредактировал(а) xvr - 3.12.2007, 15:32

Каждый поток имеет свой собственный стек, по умолчанию стек равен 8 метров. Получается если в какой-то момент у процесса оказалось 300 рабочих потоков, то только их стек занял 2.5 гига виртуальной памяти. Всего на 32-битной системе процесс  может забрать около 3 гиг,  кажется даже чуть меньше. Вот и получается нехватка памяти.

vinick, 
в таком случае используется swap
+ стек расширяется динамически, по мере надобности

Своп используется когда заканчивается физическая оперативная память. Я же говорю о виртуальном адресном пространстве процесса, когда оно заканчивается то получается out of memory. В 32-битных системах процесс может адресовать всего 4 гига памяти, но в linux около гига забирает ядро и по-моему что-то отдается загруженным динамическим библиотекам, итого процессу на личные нужды остается меньше 3 гиг. На каждый созданный поток по умолчанию резервируется 8 метров стека из этого адресного пространства, если потоков много, то их стек съедает все.

Расширяемость стека к топику не относится. Но стало интересно 
Я не смог найти в сети ни подтверждений вашего тезиса ни опровержения. Но вот такой пример при ulimit -s == 8192 почучает ошибку сегментирования. Или стек надо какими-то системными вызовами принудительно расширять?

Ядру гиг не нужен. Просто память некоторых устройств (видеокарт, например) отображается в адресное пространство процессора. Это приводит к тому, что когда установлено 4Гига памяти, часть из нее перекрывается отображаемой памятью. И это не только в Linux.

bsa, 
цитата отсюда


Не путайте физически установленную оперативную память и вирутальную память. Это немного разные вещи.

vinick, 

вот мое маленькое исследование



далее смотрим /proc/3862/maps (PID = 3862)

получаем

7fff3e36c000 - 7fff3e355000 = 94208 байт
далее посылаем процессу сигнал SIGUSR1

опять смотрим /proc/3862/maps

7fff3e36c000 - 7fff3e2e7000 = 544768
отсюда можно сделать однозначный вывод о расширении стека вниз
и он будет расширяться, пока не будет достигнут лимит на его размер
этот лимит равен ~ 8MB

Код моего приложения примерно следующий: