The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"pthread_deteach и странности с выделением памяти"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Программирование под UNIX (Public)
Изначальное сообщение [Проследить за развитием треда]

"pthread_deteach и странности с выделением памяти"  
Сообщение от Dip email on 09-Мрт-06, 09:45 
Написал сервак, который слушает сокет, и на каждое входящее соединение создает тред, который просто держит открытый сокет 1 секунду и завершается. Так вот этот сервер себя непонятно ведет. При массовой бомбежке со стороны клиента, когда создается много тредов, он отжирает около 50 метров памяти. Но на утечку не похоже, потому как при повторной бомбежке отожранная память либо не увеличивается, либо увеличивается на пару килобайт.
В тредовой функции память нигде не выделяется, может я просто что-то не утилизирую из того, что создает система при создании треда?
В man pthread_detach написано, что детаченный тред может освободить ресурсы по завершению самого себя. Но может - это же не должен! Может это если ресурсов не хватает? А так держит копии тредовых функций в памяти, типа чтоб потом время на повторное выделение не тратить...
Если кто знает, из-за чего может быть проблема, пожалуйста, подскажите. Или хоть в какую сторону копать намекните.
Система - freebsd.
Спасибо!
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "pthread_deteach и странности с выделением памяти"  
Сообщение от DeadMustdie email(??) on 10-Мрт-06, 10:28 
Скорее всего, плодит много поточных стеков. Можно попробовать задать меньший размер стека
при создании новых потоков. А память системе потом не отдаётся, так аллокатор устроен.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "pthread_deteach и странности с выделением памяти"  
Сообщение от Dip email on 10-Мрт-06, 14:17 
>Скорее всего, плодит много поточных стеков. Можно попробовать задать меньший размер стека
>
>при создании новых потоков. А память системе потом не отдаётся, так аллокатор
>устроен.
А уже выделенная под стеки потоков память потом используется другими вновь созданными потоками? Или выделяется снова? Т.е. сервер будет разрастаться до размера, соответствующего кол-ву тредов при максимальной нагрузке и на этом остановится, или будет расти постоянно?
И еще вопрос. Как определить минимально необходимый размер стека? Опытным что ли путем?
Как вообще лучше выкручиваться, если мне нужен сервер, ориентированный на обработку по схеме открытие соединения - короткий ответ через него - закрытие соединения? Может литературой какой кто в меня кинет? А то сам ничего толкового не найду.
Спасибо.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

3. "pthread_deteach и странности с выделением памяти"  
Сообщение от DeadMustdie email(??) on 10-Мрт-06, 14:29 
>А уже выделенная под стеки потоков память потом используется другими вновь созданными
>потоками? Или выделяется снова? Т.е. сервер будет разрастаться до размера,
>соответствующего кол-ву тредов при максимальной нагрузке и на этом остановится, или
>будет расти постоянно?

Память используется повторно. Рост возможен только при дальнейшем увеличении количества
одновременно запущенных потоков.

>И еще вопрос. Как определить минимально необходимый размер стека? Опытным что ли
>путем?

Зависит от программы, естественно. Кому-то 64K с ушами хватает, другим 1M мало.
На разных платформах вдобавок по-разному получается. Так что стоит попробовать,
если случаются спорадические SIGSEGV от вылета за границы стека - увеличить.

>Как вообще лучше выкручиваться, если мне нужен сервер, ориентированный на обработку по
>схеме открытие соединения - короткий ответ через него - закрытие соединения?
>Может литературой какой кто в меня кинет? А то сам ничего
>толкового не найду.
>Спасибо.

Лучше не плодить по потоку на каждое соединение, а создать выделенный пул из
фиксированного числа рабочих потоков. В главном потоке ловить новые подключения
либо активность на уже существующих подключениях с помощью poll()/select().
Затем дескрипторы соединений с клиентами помещать в очередь. Рабочие потоки
должны дескрипторы по одному из очереди забирать, выполнять работу с клиентом
и дескриптор возвращать главному потоку (или закрывать, если на каждую операцию
открывается отдельное соединение). Схема, в принципе, стандартная.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "pthread_deteach и странности с выделением памяти"  
Сообщение от Dip email on 13-Мрт-06, 10:45 
Просто огромное человеческое спасибо!
Теперь у меня появилась уверенность в том, что я иду верным путем.

P.S. Еще один немножко отвлеченный вопрос. При программировании с использованием pthread обязательно использовать функции типа strerror_r и прочие *_r? А то в одних источниках написано что надо, в других они вообще не упоминаются. А еще где-то вычитал, что компилятор сам заменяет * на *_r... Интересно как? Ведь например в freebsd char *strerror(int), но int strerror_r(int,char *, size_t)...

P.P.S. Если кто-нибудь проявит гуманизм, и вышлет мне хорошую книжку по сетевому/системному программированию на spammerbox[a]land.ru, то я перестану мучаться и больше не буду надоедать людям вопросами. Книжку можно на английском. Спасибо.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

5. "pthread_deteach и странности с выделением памяти"  
Сообщение от chip email(ok) on 13-Мрт-06, 12:05 
>Просто огромное человеческое спасибо!
>Теперь у меня появилась уверенность в том, что я иду верным путем.
>
>
>P.S. Еще один немножко отвлеченный вопрос. При программировании с использованием pthread обязательно
>использовать функции типа strerror_r и прочие *_r?

Нужно использовать thread safe (reentrant) функции. Не есть истина, что они все заканчиваются *_r.

>А то в одних
>источниках написано что надо, в других они вообще не упоминаются. А
>еще где-то вычитал, что компилятор сам заменяет * на *_r...

Это что-то новенькое, из области фантастики.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "pthread_deteach и странности с выделением памяти"  
Сообщение от Dip email on 13-Мрт-06, 14:05 
>Нужно использовать thread safe (reentrant) функции. Не есть истина, что они все
>заканчиваются *_r.
А как узнать, является функция thread-safe или нет? В манах вроде нету...
>
>Это что-то новенькое, из области фантастики.
Вот я тоже почему-то так подумал :)
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

7. "pthread_deteach и странности с выделением памяти"  
Сообщение от chip email(ok) on 16-Мрт-06, 17:07 
>>Нужно использовать thread safe (reentrant) функции. Не есть истина, что они все
>>заканчиваются *_r.
>А как узнать, является функция thread-safe или нет? В манах вроде нету...

Вестимо в ее исходниках :(. Во многих случаях можно догодаться по функционированию функции. В качестве, примера strtok[_r]

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "pthread_deteach и странности с выделением памяти"  
Сообщение от DeadMustdie email(??) on 16-Мрт-06, 20:34 
>>А как узнать, является функция thread-safe или нет? В манах вроде нету...
>
>Вестимо в ее исходниках :(. Во многих случаях можно догодаться по функционированию
>функции. В качестве, примера strtok[_r]

В нормальных манах - пишут. В Солярисных, например, специальный атрибут есть.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру