Здравствуйте, gandjustas, Вы писали:

G>Ты пытаешься свою теорию воткнуть туда, где она не нужна.

Т.е. ты по ссылке не ходил?
А там вполне конкретная задача разбиралась.


V>>Каждая асинхронная операция имеет возможность завершится конкурентно с другой, если реактор у нас работает, например, на пуле потоков поверх IOCP. Поэтому, прежде чем делать что-то асинхронно, в первую очередь необходимо выяснить потоковую модель такой асинхронности.
G>Завершаться может когда угодно, а коллбеки в JS вызываются строго последовательно. Если же ты попробуешь иницииоровать две асинхронные операции с одним ресурсом в одно время, о получишь или ошибку или одна выполнится после другой. Так что состояние гонки в js ты не получишь никаким образом.

Так вот, разбиралась задача чтения из файла в случае асинхронщины.
У коллеги получалось так, что колбэки от асинхронных операций приходили не в той последовательности, в какой инициировались.
И это нормально для того же overlapped io в виндах, когда мы инициируем более одной асинхронной операции над хендлом, обслуживаемым через IOCP на пуле потоков.

Так вот, к счастью (или нет, ХЗ), но node.js умеет обслуживать один хендл только из одного потока.
Поэтому моя доработка кода коллеги свелась к тому, чтобы разные асинхронные операции использовали общий хендл файла, а не каждый свой при shared-режиме открытия файла.

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


V>>В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках.
G>Нет. Никакой ввод-вывод в других потоках не исполняется.

Боже, какое нубство. )))


G>Есть один поток выполнения

Есть поток выполнения колбэков одного JS-скрипта.


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

Из потоков io в очередь потока JS-интерпретатора вставляются колбэки.
Посмотри исходник, там не сложно — каждая структура, привязанная к хендлу, содержит ссылку на т.н. "контекст исполнения".
Вот в очередь к этому контексту исполнения и копируются колбэки из других потоков.


V>>Причем, я твоё непонимание показываю в каждом сообщении, а ты всё обещал показать моё — но так и не смог.
G>Чувак, ты о чем? Ты даже про модульность в JS не в курсе. Это проблема решенная 5 лет назад. Ты продолжаешь доказывать, что модульности нет. О чем с тобой еще говорить?

В JS модульности нет и не спорь, бо это дилетанство как оно есть.
Потому что я хорошо знаю, как эмулируется модульность в библиотеках JS — этот трюк прост, как и способы его обхода (даже случайного).
Т.е. из-за ошибки программиста в стороннем модуле вся эта "модульность" может улететь к чертям собачьим.

В JS есть некие соглашения о том, как совместными усилиями разработчиков "модулей" не гадить друг другу в пространство имён.
Но "соглашения" — не есть модульность.


G>Если ты хочешь мою личность обсудить, то ты не туда пришел.

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


G>>>И большинству это не помогает. Люди находят workaround и пользуются им всю жизнь, так и продолжая не понимать суть.
V>>Ну это про маньяков каких нить. ))
G>Это про подавляющее большинство программистов.

По себе других не судят.


G>>>Вот недавно захожу в раздел C++ на форуме, а там совершенно искренний вопрос как вернуть char* из функции. И половина советует делать static.
V>>Ссылка?
G>http://rsdn.org/forum/cpp/6722750.flat

Автор: Jumangee
Дата: 11.03.17

Явно студент.


V>>Половина спрашивающих на форуме С++ — это студенты или вчерашние студенты.
G>Это как раз показывает средний уровень.

Средний уровень спрашивающих?


V>>>>Я уже всё сказал:
V>>>>

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

G>>>Как это связано с языками? Сложные задачи могут быть на любом языке.

V>>Не на любом.
G>Докажи.

V>>Если для node.js на C++ не напишешь АПИ на некую нейтивную функциональность, то вот уже и нет решения на JS.
G>Нейтивная функциональность в области, где работает nodejs нужна чуть реже, чем никогда.

Я тебя расстрою — почти вся функциональность node.js нейтивная.
Я имею ввиду основные его JS-либы.
Это всё обертки.


G>Да и прокидывание нейтивной функциональности в NodeJS сложной задачей не является от слова совсем.

Тем не менее, для прокидывания такой функциональности надо быть нейтивным спецом явно посерьезнее, чем спрашивающий на форуме по ссылке.
Получается, ты сам себе противоречишь. ))


V>>JS как язык внутри пуст как абстрактное зеро.
G>Что значит "внутри пуст"? Какой яызк внутри непуст?

С++, C#.
Оба умеют работать с АПИ ОС, т.е. оба могут реализовать любую востребованную функциональность.


V>>Вся его полезная функциональность поставляется нейтивным хостом или нейтивными же "обертками"-библиотеками над имеющимся плюсовым кодом.
G>У лобого яызка так. С++ тоже внутри пуст, не дёргая API ОС он вообще ничего сделать не может.

Может и делает. Например, в драйверах обращается к специальным участкам отображенной на DMA памяти, пишет в порты ввода-вывода.
Ты это и сам должен был знать, просто запамятовал в пылу спора, не? ))


V>>Поэтому, на JS сейчас пишут медленно и отлаживаются долго.
G> На JS пишут и отлаживают быстрее, чем на C++

Это уже сильно устаревшая информация.


V>>И чем больше по размерам проект, тем меньше продуктивность.
G>Везде так, как бы тебе не казалось обратное.

На проектах С++ и C# это ровно наоборот. Чем больше накапливается хелперов, чем более высокоуровневой получается "платформа" конкретного приложения, тем выразительней получаетсяя целевой код и тем проще его поддерживать.

Сам сижу на большом нейтивном проекте уже несколько лет и вижу, что его с каждым годом всё проще развивать, по мере накопления собственных библиотек. Потому что, повторюсь, в строго-типизированной среде не происходит "засорения" пространства имён, не происходит засорения перегруженных сигнатур ф-ий и т.д. А в JS можно убить любую ф-ию через создание одноимённой переменной. Или просто переопределить уже имеющуюся и знать никто не будет. ))

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