AJAX-вызовы на ту же страницу не являются ASYNC [duplicate]

Question

AJAX-вызовы на ту же страницу не являются ASYNC [duplicate]

Найти простые числа от 1 до 10000, используя замыкание в array_filter ():

$start = 2;
$step = 10000;

$stop = $start + $step;
$candidates = range($start, $stop);    
for($num = 2; $num <= sqrt($stop); ++$num){                        
    $candidates = array_filter($candidates,
        function ($v) use (&$num){
             return ($v % $num) != 0 || $v == $num ;
        }
    );
}
print_r($candidates);

Edit: 1 не является простым числом

1

javascript php ajax

задан Rick Sanchez 16 May 2018 в 09:44

1 ответ

Другие вопросы по тегам:

javascript php ajax

Похожие вопросы:

score 4 · Accepted Answer

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

Решение этого - как можно скорее вызвать session_write_close.

Немного расширенного объяснения:

Механизм хранения по умолчанию для данных сеанса это просто файловая система. Для каждого активного сеанса PHP просто помещает файл в сконфигурированный каталог сеанса и записывает на него содержимое $ _SESSION, чтобы его можно было прочитать оттуда при следующем запросе, который должен получить к нему доступ.

Теперь, если несколько экземпляров PHP-скрипта попытались записать измененные данные сеанса в этот файл «одновременно», это, очевидно, будет иметь большой потенциал конфликтов / ошибок.

Поэтому PHP ставит блокировку записи в файл сеанса, как только один экземпляр сценария обратится к сеансу - все остальные, другие запросы (одному и тому же сценарию или другому, также использующему сеанс), придется ждать, пока первый скрипт не будет выполнен с сеансом, и блокировка записи снова появляется.

По умолчанию это происходит, когда скрипт запущен. Но если у вас есть более длинные скрипты, это может легко привести к таким «блокирующим» эффектам, которые вы испытываете здесь. Решением этого является прямое указание PHP (через session_write_close): «Я закончил сессию здесь, а не собираюсь писать с нее новые или измененные данные, поэтому не стесняйтесь освобождать блокировку, поэтому что следующий скрипт может начать чтение данных сеанса ».

Важно то, что вы делаете это только после того, как ваш скрипт будет обрабатывать любые данные сеанса. Вы все еще можете читать из $ _SESSION во время остальной части скрипта, но вы больше не можете писать. (Таким образом, все, что угодно, как $_SESSION['foo'] = 'bar';, должно было потерпеть неудачу после того, как вы выпустили сеанс.)

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

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

@RickSanchez, нет, это ограничивается одним и тем же сеансом. У другого пользователя есть другой идентификатор сеанса, а также другой файл, в котором хранится информация о сеансе. Каждый сеанс имеет свой собственный файл данных. — CBroe, 16 May 2018 в 11:47