А в FF alert блокирующая операция?

Делай синхронный AJAX-запрос https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_a...

Но что-то мне подсказывает что ты какой-то кал хочешь сделать. И document.write это плохо, равно как и синхронные запросы.

А нах*я синхронный? Тогда весь смысл эксперимента теряется.

И document.write это плохо, равно как и синхронные запросы.

А, кстати, чем это плохо, в каком смысле плохо? И при чем тут синхронные запросы?

А как может быть несинхронный alert, я что-то не понимаю. JS по определению однопоточный же.

Я сам нехнепонел. Но факт остается фактом. Можешь сам попробовать. Алерт даже не блокирует другой алерт.

А как может быть несинхронный alert

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

А нах*я синхронный? Тогда весь смысл эксперимента теряется.

Что ты вообще хочешь получить? Если просто ради сравнения, то поздравляю, ты понял что Firefox и Chrome отличаются.

Да, просто эксперимент. Просто, не совсем логично, все таки получается. Например

setTimeout(function(){console.log("foo")})
console.log("bar")
//  bar
//  foo

Не используй алерты. Они — говно. Не шутка.

Синхронные запросы тоже не используй, их грозятся выпилить нахрен.

а в FF, на мое удивление — нет.

А стандарт не требует.

http://www.w3.org/TR/html5/webappapis.html#dom-alert

Optionally, pause while waiting for the user to acknowledge the message.

А вот в confirm и prompt - требует.

А вот в confirm и prompt - требует.

Щас попробовал — с ними все то же самое

Ну т.е. после алерта код отрабатывается, пока алерт показывается? Если так, то нормально, в однопоточную модель укладывается, хотя, конечно, лучше бы между браузерами было одинаковое поведение.

Я не совсем понимаю, о чем Вы говорите. Асинхронность и однопоточность — это как теплое и мягкое, по-моему.

Асинхронность означает лишь то, что код не блокирует поток. Многопоточность тут хз каким боком оказалась.

var x = 1;
...
var oldX = x;
alert("bla");
var newX = oldX + 1;
x = newX;
console.log(x);

Этот код должен выводить «2, 3» в однопоточной модели выполнения и будет выволить «2, 2», если у нас два потока выполнения (если оба alert-а вывелись одновременно и две точки выполнения «повисли»). Собственно все джаваскриптеры умеют только однопоточную модель и огромная куча библиотек поломается на многопоточном коде.

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

Я долго думал, но не догнал:) По моему, в асинхронной однопоточной модели, проблема совместного доступа тоже может возникать. Я запускаю, допустим, несколько интервалов, которые, меняют какие то переменные, в зависимости от чего-то там, или рандомно. Как я могу быть уверен, что переменная не изменилась в текущий момент? Я же не знаю, в общем случае, когда отработал тот или иной интервал. То что вы говорите, так же можно рассуждать и про многопоточную модель, у нас же кооперативность а не реальный параллелизм. То есть, одновременно два процесса не могут иметь одно и то же процессорное время. Но не будешь же стоять с ружьем и отслеживать каждый такт процессора?

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

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

var x;
...
x = 1;
y = x + 1;
...
setInterval(function() { x = 2; }, 1);

вот в этом коде я гарантированно получаю y = 2. В случае с многопоточностью – легко можно получить y = 3. Пока мой код не закончит выполнение, никуда управление не передастся. Вот когда закончит выполнение, там может и интервал запуститься. Который опять же будет работать, пока не завершит выполнение своей функции, никому не отдавая управление, ни коллбэкам от аякс-запросов, ни onclick-хендлерам, ни другим таймерам.

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

Как это не реальный параллелизм? Сейчас даже на смартфонах по 4 ядра стоит. Ещё какой реальный. С отдельными кешами для каждого ядра, так, что каждое ядро легко может видеть своё значение для разделяемой переменной.

Как это не реальный параллелизм? Сейчас даже на смартфонах по 4 ядра стоит

А что, у нас распространенные оси windows nt, linux, mac, уже перестали быть системами с вытесняющей многозадачностью? Какая разница высокоуровневым приложениям, на скольких ядрах работают их процессы? Это ничего не меняет.