Так в этом и вопрос. Какое количество нужно. Доведём ситуацию до абсурда: спутников так много, что они создали плотную сферу, защитный купол, вокруг планеты. В какой момент куча становится кучей?
Интересно, а количество спутников как-то влияет на климат? Когда их станет так много, что мы заметно почувствуем похолодание и затемнение, так как перестанет доходиь солнечный свет?)
Мне кажется, что большинству интересно с этим поиграться, пописать запросы. И понятного объяснения как это запустить - нет. Как пользоваться моделями, как оцениь вау эффект?
Может, есть проект, где прилеплен норм интерфейс и мануал?
А я правильно понял, что до пункта 9 - наш кенгуру фронтенд и бэкенд были недоступны для пользователей? И их можно было... А как вообще их можно было открыть в кластере? Глянуть на фронт в браузере, отправить запросик на бэк?
Очень интересно и очень сложно. На потоке-координаторе я сломался.
Что, куда, откуда? port1 и port2 и там и тут. Какой порт на что подписан? И вообще потерял что такое parentPort :) Читать очень сложно. На чтение только этой части ушло почти 1,5 часа.
Тем не менее всё интересно, спасибо!
В итоге, я надеюсь, что остался с примерно правильным пониманием:
сначала создаётся координатор, с ним создаётся канал для сигналов (и какой-то части данных). Координатору добавляется св-во "порт сигналов".
затем создаются обычные рабочие, с каждым создаётся канал для сигналов (и какой-то части данных). Также добавляется св-во "порт сигналов".
затем между ними создаётся канал данных. И через доступные порты сигналов (из св-тв объекта), созданные ранее, отправляются порты данных. В каждый по одному.
дальше клубок подписок. Рабочий, получив по сигнальному порту информацю о порте данных сразу его подписывает на обработчик. И магическим образом сразу что-то сигнализирует куда-то.
координатор же, получив по сигнальному порту информацию о порте данных, сначала записывает его в пул. А потом уже подписывает на него обработчик. И тоже магически что-то отправляет по сигнальному порту кому-то.
потом появляется "парент порт". Это обработчик вызовов из основнова потока. куда мы кидаем пары {id, message}. Координатор в случае получения задания должен сразу попытаться его кому-то назначить (видимо, не дожидаясь готовности потоков), а если некому - сохранить сообщение в очереди.
Потребовалось рзаве тольно немного времени, чтобы вспомнить к чему эти << и |0. Кстати, а зачем так писать? Почему не просто десятичным числом? Это какие-то трюки?
Задам только тупой вопрос: подход применим только и именно для потоков? Я имею в виду, если я создам n промисов, которые будут читать/писать каку-то глоб. переменную, ситуация гонок ведь тоже будет? И Аtomics с семафором это дело порешают?
Не статья, а скорее набор заметок. Больше вопросов, чем полезных материалов. Если я буду публиковать такие и выдавать за статьи, меня забанят)
Но все равно спасибо. Одну новую фичу я вычитал.
А заголовок - кликбейт.
Так в этом и вопрос. Какое количество нужно. Доведём ситуацию до абсурда: спутников так много, что они создали плотную сферу, защитный купол, вокруг планеты.
В какой момент куча становится кучей?
Интересно, а количество спутников как-то влияет на климат? Когда их станет так много, что мы заметно почувствуем похолодание и затемнение, так как перестанет доходиь солнечный свет?)
Как же это мерзко. Слов нет. И ведь это кто-то написал, пальчиками своими :(
Увидел форкнутый репо в коменде:
> git clone https://github.com/ASolomatin/luajwt.git
Собственно, почему не использовать оригинальный, вроде они идентичные?
И второе: почему бы предлагаемые изменения сразу в нем и не сделать? Вроде всё статично.
Блин, а я подумал, это сервис покупки в зарубежных магазах, в которых теперь обычномк человеку платить несподручно (
А это просто ещё один сбер ид или подобный.
А меня этот риск снализьпрям раздражает. Одна покупка на 600₽ - вводи код.
Следующая покупка на 6000₽ - все ок, мы верим, что это ты,ничего подтверждать не надо.
А потом сообщения, как ребёнок наделал покупок на лям зелёных.
Пуши или смс коды маст хэв всегда, имхо.
Спасибо большое за статью! Спустя столько времени, она всё еще актуальна!
Мне кажется, что большинству интересно с этим поиграться, пописать запросы. И понятного объяснения как это запустить - нет. Как пользоваться моделями, как оцениь вау эффект?
Может, есть проект, где прилеплен норм интерфейс и мануал?
Как-то к концу этой статьи я вообще перестал понимать зачем нужны values, template, charts... Теперь всё смешалось в моей голове %)
А я правильно понял, что до пункта 9 - наш кенгуру фронтенд и бэкенд были недоступны для пользователей? И их можно было... А как вообще их можно было открыть в кластере? Глянуть на фронт в браузере, отправить запросик на бэк?
Спасибо за пояснение. Я так и подумал, но почему-то засомневался.
Дочитал до конца. Хотел было спросить, как же передаётся данные отправляются обрано в основной поток, как в пред. примере (worker.postMessage),
но внимательно всё сопоставив, кажется, понял. Как вы и написали, вместо события on('message'), поток дожидается освобождения блокировки.
Прекрасные статьи, спасибо большое!
Спасибо за статью!
Прочитал пока только первую часть. И вопрос к ней:
А почему
remainне в области разделяемой памяти? Когда мы делаем--remain, тут не может быть неопределённого состояния счетчика?Очень интересно и очень сложно. На потоке-координаторе я сломался.
Что, куда, откуда? port1 и port2 и там и тут. Какой порт на что подписан? И вообще потерял что такое parentPort :) Читать очень сложно. На чтение только этой части ушло почти 1,5 часа.
Тем не менее всё интересно, спасибо!
В итоге, я надеюсь, что остался с примерно правильным пониманием:
сначала создаётся координатор, с ним создаётся канал для сигналов (и какой-то части данных). Координатору добавляется св-во "порт сигналов".
затем создаются обычные рабочие, с каждым создаётся канал для сигналов (и какой-то части данных). Также добавляется св-во "порт сигналов".
затем между ними создаётся канал данных. И через доступные порты сигналов (из св-тв объекта), созданные ранее, отправляются порты данных. В каждый по одному.
дальше клубок подписок. Рабочий, получив по сигнальному порту информацю о порте данных сразу его подписывает на обработчик. И магическим образом сразу что-то сигнализирует куда-то.
координатор же, получив по сигнальному порту информацию о порте данных, сначала записывает его в пул. А потом уже подписывает на него обработчик. И тоже магически что-то отправляет по сигнальному порту кому-то.
потом появляется "парент порт". Это обработчик вызовов из основнова потока. куда мы кидаем пары {id, message}. Координатор в случае получения задания должен сразу попытаться его кому-то назначить (видимо, не дожидаясь готовности потоков), а если некому - сохранить сообщение в очереди.
Восхитительная статья!
Потребовалось рзаве тольно немного времени, чтобы вспомнить к чему эти << и |0. Кстати, а зачем так писать? Почему не просто десятичным числом? Это какие-то трюки?
Спасибо большое за развернутый ответ. Ваша статья побудила меня самого сегодня написать ряд тестов, чтобы наконец-то уже разобраться в этом деле :)
Спасибо больше за сатью. Написано интересно!
Задам только тупой вопрос: подход применим только и именно для потоков? Я имею в виду, если я создам n промисов, которые будут читать/писать каку-то глоб. переменную, ситуация гонок ведь тоже будет? И Аtomics с семафором это дело порешают?
А подскажите дилетанту, вот нашли вы ошибку в памяти. А дальше что? Это как-то чинится в домашних условиях?
Спасибо. А для ленивых ссылку на офф доку или блог не добавите?) Вы сделали потрясающий и очень ценный анализ. Ссылка на источник - просто бонус)
Спасибо! Отличная статья! Осталось написать таки свою опенсорс либу а-ля этот сегметер, чтобы на ноде и можно было)