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

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

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

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

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

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

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

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

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

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

// wbr

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

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

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

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

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

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

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

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

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

// wbr

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

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

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

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

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

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

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

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

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

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

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

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

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

а как мне исполнить SQL запрос на сервере MySQL асинхронно?

// wbr

> а как мне исполнить SQL запрос на сервере MySQL асинхронно?

А оно что, не умеет?

тама разве не сеть лежит?

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

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

// wbr

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

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

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

// wbr

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

Не знаю

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

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

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

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

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

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

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

// wbr

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

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

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

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

// wbr

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

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

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

// wbr

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

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

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

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

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

// wbr

Дело в том, что так было не всегда, даже в случае Linux..

Вернее, в нормальной ситуации это не так - man IPC..

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

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

man ulimit

// wbr

>man ulimit

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

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

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

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

> В linux - все процессы.

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

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

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

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

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

Вообще топикстарт присмотрись к epoll для масштабируемого сервера там O(1) - правда это не так давно в linux появилось. http://www.opennet.ru/base/dev/epoll_example.txt.html где-то и на английском есть видел пример.

fido7.ru.unix.prog: FAQ appendix 1: как писать сервера

http://groups.google.co.uz/group/fido7.ru.unix.prog/browse_thread/thread/0948...#

epoll руками дергать не кошерно. Держи курс на libev

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

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