Потоки в Julia: зелёные или нормальные?

Так вот, для того, чтобы «зелёные потоки» заняли несколько ядер - они должны работать в разных настоящих потоках исполнения pthreads. А после этого они уже, на мой взгляд, перестают быть таким уж зелёными, разве нет?

Представь, у тебя задача 200 миллисекунд ждёт данных из сокета или файлового дескриптора, 100 миллисекунд обрабатывает полученное и ещё 200 миллисекунд его выводит в другой сокет или дескриптор. Сколько тебе ядер нужно серверу для непрерывной обработки пяти потоков данных?

Нет, не перестают. Давайте с другой стороны, может проще будет - есть green thread, у него есть свой мелкий стек, код, который выполняется id внутри программы и OS про него ничего не знает. Программист пишет код в этой абстракции.

Все что ему гарантируется, что эти потоки будут «как-то» выполняться, при том, так что специфика выполнения не влияет на результат, в идеале ещё fairness guarantee - то что поток, когда-нибудь выполнится, + гарантия (с какими-то оговорками), что другие green треды не влияют на поведение данного.

Все, тут вообще нету никаких других утверждений и то, как выполнять код является целиком и полностью делом системы выполнения.

Существуют 3 большие стратегии выполнения:

* 1:1 - один green тред маппим на 1 OS тред - это очень простая но ресурсоёмкая стратегия, дающая хорошие гарантии; но так обычно никто не делает * N:1 - N green тредов на 1 OS тред - то про что пишешь ты * N:M - N green тредов на M OS тредов, где N много больше M (обычно M = числу CPU). Это достаточно сложно пишется, там возникает много вопросов про то, как балансировать треды, как правильно делать foreign вызовы. Но все же многие языки делают эту модель.

Независимо от выбора стратегии зеленые треды останутся зелеными.

Например, ghc haskell, про который я тут люблю говорить умеет N:1 модель (non-threaded RTS) и N:M модель. Если я правильно кинул ссылку, то в статье что я кинул описываются детали релизации N:M модели, может быть интересно почитать на досуге.

как-то неожиданно, мне лень ставить и копаться в джулии, в других языках с N:M стратегией выполнения легких потоков проблем нету, функции вывода на экран работают прекрасно и ни о чем думать не надо, даже если поток перекинут в другой тред.

Замечания :)

По 9-му пункту - вытесняющая многозадачность предполагает переключение контекста по таймеру. Таким образом, что мы сэкономим на гринтредах, если переключение просто N раз секаунду? Я когда собирал тогда ещё ядра Linux 2.4, а потом первые 2.6 - можно было прямо в конфигурилке задавать частоту переключений: для десктопов повыше, для серверов пониже.

По 8-му - да, не абстракция, но существуют-то они внутри OS тредов, которые «вытесняемые потоки исполнения».

По 6-му пункту - если гринтреды в разных реальных/вытесняемых потоках исполнения, то они вообще никак друг с другом не соприкасаются, их, получается, переключают разные «внутриязыковые» планировщики?

Относительно N*M - я понял, что речь идёт именно о вытесняемых потоках исполнения N и M зелёных потоков. Просто исходно речь вроде шла об N процессах - и меня это конечно удивило (мне ли не знать, насколько геморно реализованы nix'овые IPC, например).

Как-то неожиданно, мне лень ставить и копаться в джулии, в других языках с N:M стратегией выполнения легких потоков проблем нету,

Исходно printf из Glibc, насколько я помню, не thread-safe, так что ничего удивительного нет...

       For an explanation of the terms used in this section, see attributes(7).

       ┌────────────────────────┬───────────────┬────────────────┐
       │Interface               │ Attribute     │ Value          │
       ├────────────────────────┼───────────────┼────────────────┤
       │printf(), fprintf(),    │ Thread safety │ MT-Safe locale │
       │sprintf(), snprintf(),  │               │                │
       │vprintf(), vfprintf(),  │               │                │
       │vsprintf(), vsnprintf() │               │                │
       └────────────────────────┴───────────────┴────────────────┘

мой man говорит так, но я могу его неверно интерпретировать

9. Переключение дороже в 100 раз даже на модных процессорах, стек грин треда 2-16kb начальный, posix_thread 8Mb, но тюнится, так? Вообще когда хочется сказать что green треды это плохо, можно green треды заменить на epoll с не фиксированными callback-ами (я знаю что говорить callback тут не правильно, но вы ведь поняли). Т.к. если юзер может добавлять новые fd (и события для таймера, на которых ждать) и что выполнять, когда это произойдет. Вот это грин треды и есть.

На самом деле RTS решает много связанных вопросов, о которых думать не надо.

8. Я не вижу проблем в шедулере внутри шедулера, более того я вижу смысл от самописанного шедулера, внутри языка с легкими потоками. Это может быть полезно когда нужно реализовывать разные стратегии планировки, которые зависят от задачи, например FIFO для IO bound и FILO для CPU bound тредов.

6. да их переключают/(синхронизуют если нужно для GC) внутриязыковые планировщики.

Если я где-то сказал N процессов, то я сделал это зря. Если честно я нигде не видел того, чтобы раскидывали на процессы, и не представляю зачем это может быть нужно. Можно erlang к такому отнести и ему подобные решения, но это все равно не то.

UPD. знаю, для языков со stop the world GC могут быть бонусы от разнесения по разным процессам.

Нет, всё верно, значит всё-таки Thread-safe. Забавно, что код, не выполняющий print в любом виде, выполняется многопоточно без проблем.

С вашей логикой нужно вообще подальше от IT держаться.

вообще 99% смысла потоков - в том, чтобы легко шарить данные.

в моде вроде имутабельность, не?

Именно по той самой причине, о которой я сказал в самом начале: это не параллелизм, это какая-то имитация бурной деятельности.

Потому что многопоточность - это многопоточность, параллелизм - это параллелизм.

Например, подход python в духе «20 инструкций этого потока, потом 20 - другого» - хорош тольк тогда, когда 20 инструкций одного потока выполняются примерно столько же, сколько и 20 другого, а ещё есть данная Высшими Силами абсолютная гарантия того, что одна из 20-ти инструкций не приведёт к подвисанию потока на пару минуточек.

Потому что GIL надо отпускать! Или вам сказали что в питоне всё так просто, что справится любой идиот, и вы поверили?

Многопоточность - это либо параллелизм, либо псевдопаралеллизм, и нужна в любом случае для параллельного выполнения заданий. А уж для чего они выполняются параллельно (даже если и псевдо-) - дело десятое. «Многопоточность» в полном вакууме не существует. Я понимаю любовь программистов к придумываемым ими же словечкам, но не нужно голову-то терять.

anonymous под многопоточностью понимает concurrency. Есть 2 well established слова *concurrency* и *parallelism*, на русский переводящиеся, как «параллельные вычисления», хотя термины разные и оно не является «псевдо-другим».

Ну вот объясни мне, уважаемый эксперт, почему вы настолько экспертны? Ваша экспертность резанула мне глаз даже при пролистывания темы «по диагонали».

Переключение дороже в 100 раз даже на модных процессорах

Не верно. Никакое переключение не дороже, да и его там нет. Ваши представление о мире осталось за гранью реальности - на обочине истории, а именно примерно в районе 95года, а может даже раньше.

Гринтреды го нихрена не быстрее птредов. Я советую, всё же, соотносить свои «познания» с реальностью, а не маркетинговым булшитом ориентированным на терминально лсных домохозяек.

posix_thread 8Mb, но тюнится, так?

Та же самая проблема. Эти 8мб никакого отношения к тем мегабайтам, о которых ты подумал, не имеют.

Я не вижу проблем в шедулере внутри шедулера, более того я вижу смысл от самописанного шедулера, внутри языка с легкими потоками. Это может быть полезно когда нужно реализовывать разные стратегии планировки, которые зависят от задачи, например FIFO для IO bound и FILO для CPU bound тредов.

А можно узнать - зачем нужны эти «грин»-«треды»?

цифры, бенчмаркинг статьи, развернутые комментарии, если ты вообще хочешь, чтобы твоё мнение было интересно. Пока ты неотличим от низкоуровневого тролля.

цифры, бенчмаркинг статьи

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

При этом меня удивляет то, что ты пруфцевать не должен, а я должен? При этом ты никак не попытался защитить свою ТЗ и опровергнуть мою, а из этого следует лишь одно - ты ретранслятор.

Если бы ты знал почему там 8мб - ты мне доказал, что я неправ. Но ты не смог. И причину я уже назвал.

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

А по поводу бенчмарков: https://habrahabr.ru/post/306768/#comment_9725810

100500 тредов запускается? Каждый по 8 метров. И того в районе терабайта по памяти, если считать по твои выкладкам, что явно несоответствует реальности.

Так же и с производительностью самих тредов.

Как же я люблю вас, экспертов. Прочитал какую-то херню в каком-то днищебложике и уже решил, что он эксперт и может кому-то что-то ретранслировать. Это так не работает.

А по поводу бенчмарков: https://habrahabr.ru/post/306768/#comment_9725810

Для начала — автор комментария по ссылке даже не в курсе, отчего он упёрся в лимит в 30к потоков. Ну вот даже не подозревает и узнать не хочет. Это забавно.

А так вариант на Go отрабатывает у меня за 0m0,113s, тогда как вариант с pthread — за 0m0,727s. В обоих случаях брал максимальное время. Если брать среднее, то выходит 0,05 секунд против 0,65. И вариант с реальными тредами сегфолтится от раза к разу, ибо дефолтные лимиты я не увеличивал.

Копируют потому, что на шареные нужно ставить блокировки, и прощай параллелизм.

низкоуровневого тролля

DirectTroll12®

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

Для начала — автор комментария по ссылке даже не в курсе, отчего он упёрся в лимит в 30к потоков. Ну вот даже не подозревает и узнать не хочет. Это забавно.

Я смотрел код ведра, считал эти дефайны и на какой-то итерации я понял, что ограничение это ограничено чисто шизофренией и мне это стало не интересно. Если ты думаешь, что какой-то нулёвый алёша в чём-то может разобраться лучше меня - у меня для тебя плохие новости.

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

Точно так же мне не интересна и эта бесполезная задача запуска более 30к тредов. Я доказал, что го-адепты балаболы. Доказал. Остальное меня волнует мало.

Если брать среднее, то выходит 0,05 секунд

Врёшь. https://pastebin.com/cPUYxKDs

По поводу всего остального. Из твоего ответа ничего не слеудет. Запущено больше рама/8мб? Больше. Разница не в 100раз? Не в сто. Разницу ты намерил в 6.

разобраться лучше меня

Да кто угодно разбирается в этом лучше тебя. Нет в ядре жёсткой границы в 30к нитей. У меня в системе, например, лимит по умолчанию установлен в десять с чем-то тысяч. Но это легко поднимается, и 100500 нитей легко создаются.

Врёшь. https://pastebin.com/cPUYxKDs

Ой. Да ты просто туповат.

Да кто угодно разбирается в этом лучше тебя. Нет в ядре жёсткой границы в 30к нитей. У меня в системе, например, лимит по умолчанию установлен в десять с чем-то тысяч. Но это легко поднимается, и 100500 нитей легко создаются.

Поподробнее об этом. Как мне запустить 100500 нитей?

Ой. Да ты просто туповат.

Действительно.

Как мне запустить 100500 нитей?

Обычно ограничено число процессов, число нитей, число открытых файлов и число mmap областей. Ещё в случае с systemd есть ограничения на число pid в cgroup. Все эти лимиты нужно увеличить.

Обычно ограничено число процессов, число нитей, число открытых файлов и число mmap областей.

Всё это стоит выше ляма. макстред( не ставится выше 100к с копейкой). Неработает. На всё это я выходил. Всё это я увеличивал. Как и говорил - я вышел на ограничение в ведре - уже не помню что он там считал, толи раму, толи вм, но в любом случае там именно что упиралось в захардкоренное значение.

там именно что упиралось в захардкоренное значение

Не видел такого. У меня увеличивается без проблем.

В таком варианте, работает?

int main() {
  std::atomic<size_t> c{0};
  size_t n = 100500;
  
  for(size_t i = 0; i < n; ++i) std::thread{[&](){
    ++c;
     sleep(10);
  }}.detach();
  while(c < n) {}
  fprintf(stderr, "%lu\n", (size_t)c);
}

а n = 150000?

Может в системд какая проблема - у меня раньше его не было. Но я никакие лимиты в нём не ставил. Поищу потом.

а n = 150000?

В 125 тыщ с копейками упирается. Выяснилось, что в ядре не даёт установить лимит на число нитей выше определённого значения, так чтобы занимаемый ими объём не превышал одной восьмой от доступного ОЗУ. Ставишь больше памяти — получаешь больше нитей.

Ну, собственно, это я и находил тогда. Действительно - вспомнил, что зависело от кол-ва памяти. А ты обвинял меня, подлец, в том, что я не разбирался. Фу таким быть.

Ну сейчас у меня падает совсем на копейках - значит это подлое системд меня где-то подставило.

что я не разбирался

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

Но ты только подумай — миллион нитей сожрут как минимум 16 гигов. Но ты эти гигабайты не увидишь.

Не понимаю. Совсем. Есть потоки исполнения, давайте говорить о них. Потоки исполнения в рамках одного процесса просто разделяют данные, таблицы страниц ОЗУ, у них один и тот же TSS.
Так вот, для того, чтобы «зелёные потоки» заняли несколько ядер - они должны работать в разных настоящих потоках исполнения pthreads. А после этого они уже, на мой взгляд, перестают быть таким уж зелёными, разве нет?

У тебя есть 6 ядер. Только для тебя. Повесь на них 6 потоков и context switch не произойдет никогда. Но у тебя 12 задач. И ты вешаешь 2 задачи на одно ядро – получаешь 1 context switch на каждое ядро на шаг работы программы. Но 6 твоих задач могут быть «зелеными» – они могут безопастно засыпать и просыпаться в любой момент. Тогда ты выделяешь (например*) 3 ядра для «классических» потоков и 3 ядра для «зеленых» и получаешь в два раза меньше context switch'ей.

*в реальности надо бенчить что даст максимальный перфоманс.

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

Обходится что?

Ты мне предлагаешь вот это обойти: https://code.woboq.org/linux/linux/kernel/fork.c.html#427

Но ты только подумай — миллион нитей сожрут как минимум 16 гигов. Но ты эти гигабайты не увидишь.

Сколько они сожрут в го? Это всего менее 20к на нить + стек. Хотя я, конечно, не понимаю нахрена ядру целых 20к на нить, но что поделать.

Ты мне предлагаешь вот это обойти

Для экспериментов — можно. Для продакшена столько нитей использовать — идиотизм. Больше 200–300 уже будут доставлять проблемы. man c10k problem.

Сколько они сожрут в го?

Спроси у специалистов по Go. Но я сомневаюсь, что там много. Это не эмуляция фиберов для обычного Си-кода, там нет нужды выделять стек и переключаться на него. По сути, это эквивалент кода на колбеках в Си, только без боли.

Хотя я, конечно, не понимаю нахрена ядру целых 20к на нить

Тут тебе нужно почитать про то, что такое нити в Linux и чем они отличаются от процессов.

и получаешь в два раза меньше context switch'ей.

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

Для экспериментов — можно. Для продакшена столько нитей использовать — идиотизм. Больше 200–300 уже будут доставлять проблемы.

Не будут.

man c10k problem.

Это убогий мусор для развода ламерков и строчения статеек на помойках, который протух и не актуален уже десять лет. Как и рассуждения про «медленные сисколы», «медленные треды», «8мегабайт на тред + тачка виснет уже на 20» и прочий мусор.

Я тут уже много подобных экспертов-жертв протухшей макулатуры видел. Одни мне доказывали, что спринтф+мусор будут быстрее open+openat, другие что на 50тредах загнётся. В конечном итоге все они из треда почему-то улетали.

Спроси у специалистов по Go. Но я сомневаюсь, что там много. Это не эмуляция фиберов для обычного Си-кода, там нет нужды выделять стек и переключаться на него.

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

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

Тут тебе нужно почитать про то, что такое нити в Linux и чем они отличаются от процессов.

Я не об этом. Это мне никак не поможет и ничего мне не даст. Естественно если оно память жрёт, то оно там что-то хранит. А что конкретно оно там хранится - меня волнует мало. Из нужного там контекст на максиму 1к + ну максимум 2-3к. Остальное всё - это заморочки ведра, которые к делу отношения не имеют.

Первый тык: https://code.woboq.org/data/symbol.html?root=../linux/&ref=task_struct

А тут уже -3к на ненужную отладочную фигню бам, а там ещё нума-хренума, а там ещё битмаска на 500+ ненужных цпу. Всякие цгрупы и прочее.

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

В конечном итоге все они из треда почему-то улетали.

Ну давай сделай веб-сервер по принципу одно соединение — один тред. Посмотрим, сколько он выдаст и когда он загнётся. Сравниваем с nginx. Или ты сразу из треда улетаешь? ^_^

сравниваем мы гринтреды( т.е. юзерспейс треды) и обычные( кернелспейс) <...> И там и там должен быть стек.

Лолшто? Зачем?

Из нужного там контекст на максиму 1к + ну максимум 2-3к.

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

Ну давай сделай веб-сервер по принципу одно соединение — один тред. Посмотрим, сколько он выдаст и когда он загнётся. Сравниваем с nginx. Или ты сразу из треда улетаешь? ^_^

Пошла херня опять. То он болтает про «man c10k problem», то как только поплыл уже начинает сливаться на «сделай быстрее нгинкса». c10k - это про 10к коннектов, а не про нгинкс. Работоспособность 10к тредов доказана? Доказана. Вылетел? Вылетел.

Ах ну и да, вебсервер не нужен. Нгинкс - это пускалка пхп. Пхп это пускалка ворпресса. Вордпресс больше 50рпс не выдаёт. 50тредов за глаза хватит.

Лолшто? Зачем?

Я написал. Для того, чтобы мочь стопнуть его в любой момент. И вообще стопнуть.

Ух-ты. Ни малейшего представления о том, что там хранится, и при этом полное нежелание выяснять.

Опять болтаешь херню. То, что там хранится никакого отношения к теме не имеет. То, что хранится в линуксе - это отдельная реализация и напихать в неё можно всё что угодно. Но к тому, что это хранимое необходимо для работы тредов вообще это отношения не имеет.

Ты можешь попытаться взять ту структуруку и попытаться обосновать необходимость каких-то полей в контексте не линукса и вылетить из треда.

Я тебе даю задачу - каким образом цгрупс связан с тредами? И нахрена он нужен? А он не нужен. Точно так же я тебе привёл пример с CONFIG_LOCKDEP, которйы нахрен не упёрлся тредам.

Ты ни на один вопрос не ответил и причина проста - вылетишь из треда в момент.

c10k - это про 10к коннектов, а не про нгинкс. Работоспособность 10к тредов доказана? Доказана. Вылетел? Вылетел.

Вот ты и слился. Как языком молоть, так крутой. А на простенькой задаче лапки поднял и что-то там про работоспособность мямлит. Нет, пока не покажешь рабочий пример, ты просто балабол.

Нгинкс - это пускалка пхп.

Какую же ты чушь пишешь.

Я написал. Для того, чтобы мочь стопнуть его в любой момент. И вообще стопнуть.

Ты придумал что-то своё и теперь споришь. Какой смысл спора, если ты витаешь в каком-то своём мире и с общепринятыми понятиями не пересекаешься?

Я тебе даю задачу

Сервер сначала напиши. Ишь чего о себе возомнил.

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

Если ты не осилишь базовые вещи сначала освоить, то таки да, смысла с тобой разговаривать больше нет. Можешь считать, что я «вылетел из треда». Порадуйся там, что ли. Победитель, все дела. :-)

Мне всегда по наивности и незнанию казалось, что стек нужен для вызова функций: конечно разные треды не могут использовать один и тот же стек при вызове функций, по этой самой причине у каждого треда он свой. Собственно, стек при вызове функций тоже не сильно нужен, ведь можно передавать параметры через регистры, но есть одна засада, которую не обойдёшь никак: в стек отправляется адрес смещения в сегменте cs, на который нужно будет вернуться инструкцией ret (можно и «вручную» сделать то же, что делает ret). Хотя я лично всеми оставшимися конечностями за то, чтобы передавать параметры в регистрах процессора, в том числе и указатели на области памяти в сегментах данных, что в общем случае нарушает ключевую концепцию функциональщины (результат работы функции определяется только её входными параметрами, у функции не должно быть побочных эффектов).

Смысл треда в том, чтобы можно было его стопнуть в любом месте.

В стране торгашей, занимающихся уёб-комерцией - да.

А так вообще смысл тредов в организации параллельных вычислений. Есть ещё всякие неведомые штуки типа MPI, которые позволяют организовать распределённые вычисления, но всё это в СР не нужно, да. У нас только веб-серверы, реклама и массовые перепродажи дешёвого китайского дерьма. Обслужить (читай - на*бать) больше тупоголовых потребл*дских хомячков в единицу времени - вот предел мечтаний отчественного бузинеса. И тут конечно IO страшно всё тормозит, самая критичная задача - обойти треклятое IO на повороте, а не использовать максимальное число циклов CPU в единицу времени.

У СР один верный путь - в СГ. Это давно известно, нам всем туда, так что давайте идти туда дружно.

То, что ты пишешь — в каком-то смысле верно. Если хочется сделать сопрограммы, которые могут использоваться в Си-программах, без стека не обойтись. И существующие реализации сопрограмм переключают стек.

Но если у тебя другой язык, требование «настоящего» стека пропадает. Ведь на самом деле тебе нужен не стек, а контекст задачи. И тут уже переключать стек не нужно. Можно, например, неявно передавать указатель на структуру в каждую функцию.

получаешь 1 context switch на каждое ядро на шаг работы программы.

Что ещё за шаг работы программы?

Мне кажется или со вчерашнего дня принудительное переключение потоков исполнения по самому обычному таймеру уже отменили? Теперь ОС знает тайны того кода, который внутри неё работает - и даже про некие «шаги работы» осведомлена.

Т.е. не просто по тику таймера планировщик ядра, отобравший управление у предыдущего потока исполнения принимает решение о переключении на следующий в соответствии с заданной стратегией планирования (которую, AFAIK, можно менять прямо во время работы ОС) - а что-то такое вообще магическое происходит с шагами. Где почитать об этом?

Какой бы ни был язык, он же всё равно как минимум в своём ядре использует банальную инструкцию call (если речь об Intel-архитектуре, о других ничего не скажу, не знаю). И внутри потока вызовы встроенных функций ЯП - скорее всего, те же call'ы. А они без стека не живут, к сожалению.

Ну и для каждого потока ядро ОС хранит его состояние (регистры процессора в первую очередь) - только это никакой не «стек». Вроде бы даже ядро Linux не забило на TSS, использует штатную реализацию Intel, хотя для переключения задач Торвальдс изобрёл свой легковесный велосипед.

Хотя, гм, насчёт никакого не стека я что-то гоню. Блин, уже забыл всё напрочь, что знал насчёт всех этих TSS, LDT, GDT, IDT, PDPR

В контексте Go (и не только), ЕМНИП количество «потоков» (в данном случае сопрограмм - goroutine, которым нужен только контекст) != количество нативных потоков и их отображение решается внутренним планировщиком.

Да, так и есть. Обсуждали выше.

Вот ты и слился. Как языком молоть, так крутой. А на простенькой задаче лапки поднял и что-то там про работоспособность мямлит. Нет, пока не покажешь рабочий пример, ты просто балабол.

Смотри, ты утверждаешь c10k и прячешься за нгинкс. Т.е. ты утверждаешь по сути «не можешь», я утверждаю обратное. Почему ты можешь использовать как пруф готовое, а я не могу?

Тем более c10k не имеет никакого отношения к вебчику.

Ты придумал что-то своё и теперь споришь. Какой смысл спора, если ты витаешь в каком-то своём мире и с общепринятыми понятиями не пересекаешься?

Да нет, ты просто поплыл в очередной раз. Общепринятое понятие «Тред» никаким образом не относится к понятию «конкретная реализация тредов в линуксе». Я говорил о первом, а ты слился на второе. Далее сломался и начал нести бред.

Если ты не осилишь базовые вещи сначала освоить, то таки да, смысла с тобой разговаривать больше нет. Можешь считать, что я «вылетел из треда». Порадуйся там, что ли. Победитель, все дела. :-)

Бла-бла. Домохозяйки в ютубе мне то же самое говорят. Как только одна извилина закипает - в меня начинает литься «да, я не я - ты не понимаешь базовые вещи».

Причина этого проста. Любой адепт и любяа домохозяйка является ретранслятором того, что услышала в интернете. Она просто болтает и ретранслирует. Т.е. каждая «вещь», которая крутится в её черепушки не имеет никакого обоснования. Она просто там плавает.

И когда ты начинаешь об этих вещах спрашивать домохозяйку - как и почему. Она не может ответить. У неё просто в голове есть это поверье и всё. Она не может ничего с эти поделать.

Она привыкла, что её окружение читала те же интернеты и влито в собратьев то же, что влито и в её черепушку. Да и отбор происходит по этому «влитому». И внутри этого круга, влитое считается как само собою разумеющиеся. Это базовые вещи, вещи которые все знают. Все их знают просто потому, что знают. Как, почему и где они возникли? Кого это волнует.

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

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

Тем более c10k не имеет никакого отношения к вебчику.

Ты вообще с этой планеты?

Общепринятое понятие «Тред» никаким образом не относится к понятию «конкретная реализация тредов в линуксе».

Во-во, ты уже плывёшь, но всё ещё пытаешься делать весёлую мину при плохой игре.

Домохозяйки в ютубе мне то же самое говорят.

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

Кого это волнует.

Смотри. Ты сейчас пишешь на русском языке, а не на придуманной тобой тарабарщине. Знаешь зачем? Чтобы тебя понимали. То же самое и с терминологией, это часть языка.

Пока что я вижу, что ты пыжишься. Судя по эмоциональному окрасу, ты там какой-то крутой спец. Только вот кроме тебя никто твоего величия понять не может, потому что твой язык известен только тебе одному.

Хочешь чтобы тебя понимали — выражайся яснее.