Объясните на пальцах, в чем разница между ссылкой на переменную и на элемент массива?

AnrDaemon

Продвинутый новичок
Чисто теоретически, ты делаешь больше действий, чем предполагаешь.
Результат предсказуем.

P.S.
Вот так намного понятнее.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
колбеки? в асинхронном языке используются события, промисы, генераторы 🙄 корутины и каналы
 
Последнее редактирование:

WMix

герр M:)ller
Партнер клуба
Вот начинается, промис это коллбаск, давай уже сразу асинк.
 

ksnk

прохожий
Весь топик - какая то ересь. Это раздел PHP, не забыли ? 😀
То Фанату приспичило указатели с элементами искусственного интеллекта, то ругаются начинают не по нашенски...
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Весь топик - какая то ересь. Это раздел PHP, не забыли ? 😀
То Фанату приспичило указатели с элементами искусственного интеллекта, то ругаются начинают не по нашенски...
 
Последнее редактирование:

WMix

герр M:)ller
Партнер клуба
closure может быть обьектом, обьект может быть invocable, но сам термин promise пришел из функционального программирования и подразумевает callback
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
да я просто прикалываюсь, нет более бессмысленного спора, чем терминологический, а это базовые общеизвестные понятия
 

WMix

герр M:)ller
Партнер клуба
это же несколько другое, нет? в смысле это про несколько процессов что ведет. к расходу памяти и процессора. это не совсем про асинхронность одного потока.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
асинхронность - это когда несколько вычислительных потоков работают независимо от главного цикла, parallel про это,
а обработка нескольких запросов одновременно в одном потоке - это неблокирующий режим, он синхронный
я сам часто называю одно другим, но на самом деле, это принципиально разные понятия

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Асинхронность в общем смысле - это обработка событий, которые не координированы с главным процессом.
FPM pool, получается, асинхронная система, но каждый worker в отдельности - синхронный и блокирующий.
Никаких ограничений на количество процессов или потоков из понятия асинхронности не следует.
Причина, по которой асинхронная обработка событий переводится из множества процессов в единый - экономия на инициализации и переключении контекстов.
По сути, PHP просто продолжает сближаться с Java, создается JIT и application server. Этот процесс начался в 4й версии, когда в С-подобный синтаксис PHP принесли Java-подобный OOP.
 

WMix

герр M:)ller
Партнер клуба
не знаю как обьяснить
PHP:
$loop = React\EventLoop\Factory::create();

$counter  = 0;
$loop->addPeriodicTimer(3, function(React\EventLoop\Timer\Timer $timer) use ($counter) {
    echo $counter, PHP_EOL;
});

$loop->addPeriodicTimer(2, function(React\EventLoop\Timer\Timer $timer) use (&$counter) {
    $counter++;
});

$loop->run();
этот код можно написать и с помощью phthread и с помощью fork но явно усилий потратишь больше (ресурс counter придется делить)

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

AmdY

Пью пиво
Команда форума
довольно легко написать много асинхронных потоков, но мозги вскипят написать многопотоковость многопоточных процессов.
Зато тебе не придётся страдать от всяких локов. Недавно внедрял в проект reactphp, несмотря на то. что скрипт отрабатывает в 20 раз быстрее. под нагрузкой производительность ниже fpm в 10 раз пока не поднимешь пул независимых phpreact инстансов.
 

fixxxer

К.О.
Партнер клуба
С reactphp достаточно легко нафоркать воркеров. Очередное входящее соединение подхватит первый освободившийся воркер, так работает Unix, вообще не надо ничего особенного специально делать.

Как-то так: в мастере сделать $socket->pause() и $server->listen() (пока без запуска event loop), нафоркаться, в каждой детке сделать $socket->resume() и $loop->run(), написать обработчики сигналов ($loop->addSignal(), логика классическая, как было бы с любой master+workers архитектурой), и уже когда нафоркались, сделать $loop->run() в мастере.

Получится ровно то же, что делает php-fpm - за исключением того, что в детках тоже будет event loop.
 
Последнее редактирование:

WMix

герр M:)ller
Партнер клуба
Нафоркать это опять вопрос необходимости, хочется изолированности к примеру, я же наоборот пытаюсь сказать, что идея остаться в одном потоке, при этом работать с ресурсами асинхронно.

@AmdY, локи это одна часть головной боли, в яве обычно решалось модификатором synchronized, ассинхронность это еще и атомарность обратного вызова до тех пор пока новый callback внутрь не встроишь

Да реакт имеет несколько драйверов, и большой разницы в распареллеленом и асинхронном не будет, но думать проще одним потоком, и было бы супер еслиб он был без блокировки, а уже дальше такие процессы паралелить
 
Последнее редактирование:
Сверху