LINUX.ORG.RU

Потоки vs Процессы


0

0

подскажите, что лучше использовать для разработки многопоточного сервера потоки или дочерние процессы?

Где-то читал что ничего плодить ненадо, а всё через poll делать ... ???

Вразумите, пожалуйста. Может ссылочку где почитать. В нете искал, но еслиесть человек который с такого рода задачами сталкивался, буду благодарен за авторитетный ответ.

И ещё как быть если планируется огромное кол-во входящих соединений. Насколько знаю надо увеличить кол-во возможных дескрипторов? Может ещё что-то?

Спасибо.

anonymous

Re: Потоки vs Процессы

> Где-то читал что ничего плодить ненадо, а всё через poll делать ... ???

Да, потоков должно быть столько же сколько и ядер да и то только тогда когда увидишь, что проседает у тебя процессор, а не сеть.

> В нете искал, но еслиесть человек который с такого рода задачами сталкивался, буду благодарен за авторитетный ответ.

смотри примеры к libevent и/или boost/asio

> Насколько знаю надо увеличить кол-во возможных дескрипторов?

да, путем правки /etc/security/limits.conf

Reset ★★★★★ ()

Re: Потоки vs Процессы

если слишком много входящих соедиений, то открывать тысячи даже потоков любой ОС будет сложно

namezys ★★★★ ()
Ответ на: Re: Потоки vs Процессы от namezys

Re: Потоки vs Процессы

> если слишком много входящих соедиений, то открывать тысячи даже потоков любой ОС будет сложно

ну линукса в принципе держит несколько тысяч потоков и вполне стабильно это делает. другой вопрос - надо ли это..

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

// ну линукса в принципе держит несколько тысяч потоков

Все держим. Но там, где щас 1000, завта будет 10 000, а через месяц и вся сотня

Ну другие причины писать не буду

namezys ★★★★ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

>ну линукса в принципе держит несколько тысяч потоков и вполне стабильно это делает. другой вопрос - надо ли это..

Если нужны десятки/тысячи потоков - то это прямая дорога в Erlang :) В остальных случаев - пулы. При несложных задачах десятки потоков могут обрабатывать сотни и тысячи клиентов.

KRoN73 ★★★★★ ()
Ответ на: Re: Потоки vs Процессы от KRoN73

Re: Потоки vs Процессы

Ну можно попытаться реализовать что-то похожее на базе пулов потоков

В любом случае, тута не ситуация один поток - одна задача, Множенье потов надо для равномерной загрузки камней

namezys ★★★★ ()
Ответ на: Re: Потоки vs Процессы от KRoN73

Re: Потоки vs Процессы

> При несложных задачах десятки потоков могут обрабатывать сотни и тысячи клиентов.

да могут конечно. правда, с одним но: если им в процессе обработки не приходится общаться с задумчивыми синхронными вызовами. к примеру, лезть в MySQL базу через libmysqlclient [+ через сеть].

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

>> если им в процессе обработки не приходится общаться с задумчивыми синхронными вызовами.

А зачем это делать синхронно?

namezys ★★★★ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

Интересно! допустим: - для обработки коннекта надо лезть на сервак с MySQL. - одновременных соединений может быть тысячи.

тогда как быть? использовать потоки для соединений или в через poll делать?

Спасибо за ваши ответы!

anonymous ()
Ответ на: Re: Потоки vs Процессы от namezys

Re: Потоки vs Процессы

>В любом случае, тута не ситуация один поток - одна задача

В L2Fortress у нас использовался такой механизм. Стоит небольшой пул соединений с клиентами. Клиент присылает пакет. Сервер (в смысле - pool-часть) формирует runnable-объект для этого пакета и отправляет исполняться отдельным потоком. В результате и число одновременно работающих потоков невелико, так как клиенты шлют пакеты не непрерывно, и клиентов может быть много, и время отклика хорошее, и оба (у меня только два было) процессора грузятся.

KRoN73 ★★★★★ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

>с одним но: если им в процессе обработки не приходится общаться с задумчивыми синхронными вызовами

Да, есть такое. У нас задачи простые были в этом смысле. Все объекты, отображаемые на MySQL глобальные и грузятся/выгружаются нечасто.

KRoN73 ★★★★★ ()
Ответ на: Re: Потоки vs Процессы от KRoN73

Re: Потоки vs Процессы

Я тута для С++ написал топик

И тама преложил ... точнее что-то написал из того что у меня для такого есть

есть много идей как это развить

namezys ★★★★ ()
Ответ на: Re: Потоки vs Процессы от namezys

Re: Потоки vs Процессы

> А оно что, не умеет? тама разве не сеть лежит?

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

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от namezys

Re: Потоки vs Процессы

> Хм. Я правда не знал что не умеет

не умеет. и постгрес AFAIR не умеет, и сибейз. да собственно я и не припомню примеров тех, кто умеет. a'la разядил SQL запрос, задал ему калбек и ждёшь, когда он его там дёрнет. или в этом духе. видимо, такое де-факто не очень то и нужно народу, а в реализации при этом дюже муторно.

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

> такое де-факто не очень то и нужно народу, а в реализации при этом дюже муторно.

Не знаю

Хотя тута вопрос сложный, нужно или нет

смотря сколько времени отводится на выполнение запроса/его обработку

namezys ★★★★ ()

Re: Потоки vs Процессы

В зависимости от операционной системы.. Смотреть в сторону thread pooling для универсальности..

MiracleMan ★★★★★ ()
Ответ на: Re: Потоки vs Процессы от namezys

Re: Потоки vs Процессы

>> такое де-факто не очень то и нужно народу, а в реализации при этом дюже муторно.

Не нужно либе делать то, что клиент либы может сделать сам: запускаешь тред для общения с базой, даешь ему задание и коллбек. Сам делаешь что-то еще - когда тред получит ответ от базы - дернет коллбек. Вот вам и асинхронный вызов либы.

anonymous ()
Ответ на: Re: Потоки vs Процессы от anonymous

Re: Потоки vs Процессы

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

да можно конечно. так в том числе делают. вопрос лишь в том, что такой подход не вяжется с "централизованной раздачей" событий через диспатчер. точнее вяжется, но как то через ж. искусственно.

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

>ну линукса в принципе держит несколько тысяч потоков и вполне стабильно это делает. другой вопрос - надо ли это..

В контексте linux "Потоки vs Процессы" никакого смысла не имеет потому что они тут ничем не отличаются.

anonymous ()
Ответ на: Re: Потоки vs Процессы от anonymous

Re: Потоки vs Процессы

> В контексте linux "Потоки vs Процессы" никакого смысла не имеет потому что они тут ничем не отличаются.

ой ли? так уж и ни чем? :)

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от MiracleMan

Re: Потоки vs Процессы

> он имел в виду затраты.

ну мне сложно судить о том, что же именно имел ввиду анонимус. будем надеяться, что со временем он пояснит своё высказывание.

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

>ну мне сложно судить о том, что же именно имел ввиду анонимус. будем надеяться, что со временем он пояснит своё высказывание.

Лично я понял его именно так.. А, вообщем, да, согласен..

MiracleMan ★★★★★ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

Поток - это тот же процесс который использует совместно ресурсы с другим процессом, имеет свою task_struct. Для ядра нет никакой разницы между потоками и процессами.

anonymous ()
Ответ на: Re: Потоки vs Процессы от anonymous

Re: Потоки vs Процессы

> Поток - это тот же процесс который использует совместно ресурсы с другим процессом, имеет свою task_struct. Для ядра нет никакой разницы между потоками и процессами.

и лимиты на ресурсы надо полагать у них отрабатывают одинаково...

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

При чем ту вообще лимиты на ресурсы ? Лимиты как правило обусловлены физической составляющей а не виртуальными ресурсами. В этом одно из коренных отличий linux от других ос - там потоки это некая абстракция, более легкий вариант процесса. В linux - все процессы.

anonymous ()
Ответ на: Re: Потоки vs Процессы от anonymous

Re: Потоки vs Процессы

> При чем ту вообще лимиты на ресурсы ? Лимиты как правило обусловлены физической составляющей а не виртуальными ресурсами. В этом одно из коренных отличий linux от других ос - там потоки это некая абстракция, более легкий вариант процесса. В linux - все процессы.

man ulimit

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

>man ulimit

Ну и - дальше что ? Я что-то мысли не понял. Как у эллочки - мрак, блеск, парниша ?

anonymous ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

> что такой подход не вяжется с "централизованной раздачей" событий через диспачер.

Т.е. хочется, чтобы при обработке события от диспатчера, в случае обращения к базе
1) вызвать либу (которая должна послать запрос к базе и сразу вернуть управление не дожидаясь ответа)
2) зарегистрировать (у того же диспатчера) новое задание проверки ответа базы + коллбек продолжения обработки события
3) вернуть управление диспатчеру.

Далее диспатчер между делом вызывает процедуру обработки этого задания, которая проверяет готовность ответа базы (через либу) и, если ответ готов, дергает коллбек, иначе отваливается до следующей проверки.

anonymous ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

> что такой подход не вяжется с "централизованной раздачей" событий через диспатчер. точнее вяжется, но как то через ж. искусственно.

В twisted вяжется и вполне естесственно.

anonymous ()
Ответ на: Re: Потоки vs Процессы от anonymous

Re: Потоки vs Процессы

>Разве с приходом NPTL от этого отказались, нет?

На ЛОРе видимо отказались - а в остальном мире нет :) С приходом nptl реализацию потоков из юзерспейса перенесли на ядро. А там каждый поток - это отдельный процесс, они группируются и все потоки-процессы имеют одинаковый идентификатор группы - пид первого процесса этой группы.

anonymous ()
Ответ на: Re: Потоки vs Процессы от klalafuda

Re: Потоки vs Процессы

> не умеет. и постгрес AFAIR не умеет, и сибейз. да собственно я и не припомню примеров тех, кто умеет. a'la разядил SQL запрос, задал ему калбек и ждёшь, когда он его там дёрнет. или в этом духе. видимо, такое де-факто не очень то и нужно народу, а в реализации при этом дюже муторно.

постгрес умеет, только не калбек, а типа poll. см. http://www.postgresql.org/docs/current/static/libpq-async.html

Eshkin_kot ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.