рубистПроясним ситуац,

Аноним, с тобой общатся больше не о чем. И не тебе судить о моих знаниях.
Здесь можно закончить только фразой "Ты кто такой? Давай, досведания!"

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

До свидания, да. Удачи тебе в твой руби, может хоть там станешь похож на профи.

iv_an_ruПроясним ситуацВ линуксе процесс - это сущность из одной нити. Кури бамбук на предмет системного вызова clone()Ну так я жду рассказа, как один процесс может одновременно читать/писать несколько дисков И общаться с несколькими клиентами И выполнять нетривиальные вычисления, периодически требующие доступа к данным с тех самых дисков И вызывать процедурки на яве/perl/php --- всё в одной нити и без накладных расходов на IPC.

В школе не рассказывали про mmap, msync(MS_ASYNC), mincore и madvise? В прочем да...

И даже про fcntl( O_NONBLOCK) ioctl(fd, FIONBIO) не рассказывали (для сокетов)?
]

iv_an_ruПроясним ситуац,
Поздравляю с успешным прочтением заголовочников. Ну и чем знание умных идентификаторов вам поможет? Рантайм толстого скуля "немножко" сложнее чем фарш Xitami, его "немножко" неудобнее будет представлять в виде FSA. И что совсем порвёт вам шаблон, этот FSA будет ещё и медленнее, потому что для обеспечения нужной гранулярности вам вместо редких дорогих переключений нитей придётся срывать конвейеры проца на каждом чихе. Про цену разработки и сопровождения вообще молчу, потому что такой проект просто не будет никогда закончен. Я бы понял, если б вы, скажем, вспомнили про fibers как замену нитям, это бы показало у вас зачатки понимания проблемы, а так... тролльте поинтереснее.

iv_an_ruПроясним ситуац,
Поздравляю с успешным прочтением заголовочников. Ну и чем знание умных идентификаторов вам поможет? Рантайм толстого скуля "немножко" сложнее чем фарш Xitami, его "немножко" неудобнее будет представлять в виде FSA. И что совсем порвёт вам шаблон, этот FSA будет ещё и медленнее, потому что для обеспечения нужной гранулярности вам вместо редких дорогих переключений нитей придётся срывать конвейеры проца на каждом чихе. Про цену разработки и сопровождения вообще молчу, потому что такой проект просто не будет никогда закончен. Я бы понял, если б вы, скажем, вспомнили про fibers как замену нитям, это бы показало у вас зачатки понимания проблемы, а так... тролльте поинтереснее.


Мы не используем Xitami и не собираемся (есть собственная реализация HTTP), что такое FSA не знает даже википедия. Что это?

Про срыв конвеера проца, в сравнении с переключениями контекста - можно рассказать вот тому мальчику, который там с mysql напрышивал, он - поверит.

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

Все переключения контекста реализованы над обертками системных вызовов socket read/socket write/db.get/db.put

В большинстве случаев этого более чем достаточно - request прилетает сразу (ибо меньше размера пакета), данные файла уже в замамлены в памяти, а асинхронная отправка response и вовсе ничего от workerа не требует.

Ты просто совсем не в теме видать, и это хорошо.

iv_an_ruПроясним ситуацчто такое FSA не знает даже википедияВикипедия знает , это вы не знаете.
Автоматы знает любой студент, который изучал дискретку. Какое отношение они имеют к вопросу событийно-ориентированного асинхронного программирования?
К чему было их упоминать? Для красного словца? Ну давай я еще с "умным" видом ляпну про автоматы с магазинной памятью, а ты сиди и думай, зачем это я сказал.

iv_an_ruПроясним ситуацгранулярность порядка сильно меньше 1 мсек на один запросИ чем гордиться? Посчитайте сами, сколько строк таблицы можно пробежать за 1 лишнюю мсек,
В фразе "меньше 1 мсек" я говорил про гарантированную гранулярность. В реальности web запросы отрабатывают за намного меньшее время, за некоторыми исключниями.

iv_an_ru из расчёта два такта на строку. Хотя о чём это я? Вы ж начали с того, что изувечили базу, самовольно без спросу добавив шардинг на всё подряд.
Чуваки из ebay применяют шардинг на базах данных Oracle, чуваки из Facebook/Twitter - тоже самое, но на mysql.
Они у тебя тоже должны были разрешения спрашивать?

iv_an_ruКстати, вам с вашим шардингом латентность NUMA передавала пламенный привет :)
Полная чушь. Как раз для NUMA шардинг прописан еще и как, потому что позволяет делать реально управляемый и эффективный affinity и к процессору, и к его локальной памяти и кешам (см на netezza как пример).

Садись два, вообще не шаришь.

iv_an_ruПроясним ситуацrequest прилетает сразу (ибо меньше размера пакета), данные файла уже в замамлены в памяти, а асинхронная отправка response и вовсе ничего от workerа не требует.Если вы ничего сложнее веб-сервера не писали, то у вас тем более нет оснований поучать других.

Все, пойду наемся с горя червячков.

Можно пример чуть более сложного, чем веб-сервис? FEA расчеты подойдут?
Если я умею считать динамические нагрузки, то я могу уже поучать? Что, все еще нет? О горе мне!

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

Ок, все прослезились, ты меня уделал паполной!

iv_an_ruПроясним ситуацАвтоматы знает любой студент, который изучал дискретку. Какое отношение они имеют к вопросу событийно-ориентированного асинхронного программирования?Потому что если вы не хотите запихать всё состояние толстого рантайма в событие, то вам понадобится 1) где-то хранить это состояние и 2) предусмотреть переходы из одного класса состояний в другие. Вот вам и автомат. Тот же imatix, которым вы размахиваете, предлагал целый тулкит для написания FSA как раз по этой причине..
Открой для себя стандартные POSIX getcontext, setcontext (которые вызываются при условии что read/write не может быть выполнен прям сейчас, EWOULDBLOCK на выходе и SIGALARM (для heatberta, и вывода "закисшей" отдельно взятой сессии из бесконечного цикла).

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

iv_an_ruПроясним ситуацЧуваки из ebay применяют шардинг на базах данных Oracle, чуваки из Facebook/Twitter - тоже самое, но на mysql. Они у тебя тоже должны были разрешения спрашивать?Да нет, не должны. Просто эти "чуваки" в отличие от вас знают, когда от шардинга больше пользы, чем вреда, а когда наоборот.

Точно! Ты сейчас с ними созванивался, выяснял, что они знают, а что нет, и что они знают о том, чего я не знаю?

Просто обалдеть!

iv_an_ruПроясним ситуацпропущено...
Полная чушь. Как раз для NUMA шардинг прописан еще и как, потому что позволяет делать реально управляемый и эффективный affinity и к процессору, и к его локальной памяти и кешам (см на netezza как пример).Щасс. Вот если б вы рассматривали шардинг строго по числу NUMA-нод, это показало бы некоторую осведомлённость, а по числу ядер БД пилят только в весьма специальных случаях.


Какая-то сказочная чушь, право. Что мне мешает создать 16 шард и повесить их на одну ноду да хоть простейшим taskset/sched_setaffinity, заодно прописать set_mempolicy для mmap? Кстати, да, надо бы и FR сделать...

Ах да, сервер баз данных тоже свой, из отряда доработанного dbm (а то "понимание", что там Oracle приверчен, это лишнее, понимание т.е.)

все согласны?Господа, а вот с этим утверждением все согласны?
Тут нет господ даже близко. В основном недоученные бывшие рабоче-крестъянены с якобы дипломами

И в целом - конечно нет

Допустим если сравнить С, C# и C++ по:
фича\язык: C C# C++ООП + (есть - читай книги) + +множественное наследование ? - +шаблоны + (кури макросы) +- +перегрузка операторов - + +лямбда функции - + +сборщик мусора + (кури obstack и Boehm-Demers-Weiser conservative garbage collector for C/C++) + +