В общем то, вопрос в названии.
Я так понимаю, что если запускать таймаут таким образом "window.setTimeout", то создается объект таймер. И даже, если будет окончен таймаут, этот таймер ни куда не денется. И если его принудительно не уничтожать, то так и будет висеть, как дочерний объект window.
А если не указывать принадлежность таймера, то есть надежда, что по завершении таймаута таймер уйдет в небытие.... Не смог нарыть информации про этот механизм... Разъясните...

Что такое "таймер" - не имеет значения, механизм не раскрыт, значение имеет, чей это метод, как его запускать, и что он возвращает. Всё остальное за рамками спецификаций. Относитесь к "таймеру" проще, как к обычной функции, вы передаёте этой функции аргументы, в её теле что-то такое весёлое происходит и она возвращает нам на память волшебное число, с помощью которого мы можем отменить исполнение.


"Дочерний объект window" - это сам метод setTimeout, само собой он никуда не уходит, "таймер" же - это не объект, а процесс, отсрочка исполнения, "уничтожать" отсрочку не нужно (если надо отказаться от отсрочки, то используют соответствующий метод clearTimeout).


Принадлежность вообще не при чём. Использовать или не использовать составное(полное) имя - вопрос более общий, к setTimeout-y это относится так же, как и к любому другому свойству window.

Ghirik, "метод" setTimeout(...) (как и большинство других: window.alert(...), window.clearTimeout(...) window.confirm(...) и т.д.) изначально принадлежит объекту window. Поэтому определение этого метода там же и останется, после того, как второй поток javascript перестанет работать (а вот какой объект создается во втором потоке - называется он "таймер" или еще как - не могу сейчас сказать).

В общем, в грубом определении setTimeout - это глобальная функция, которая принадлежит window, поэтому к ней, как и к любой другой глобальной переменной, можно обращаться без "префикса" window.

Что за "второй поток javascript"? Где можно почитать, у кого разузнать?

AKS, где "научно" почитать - не скажу, не знаю сам. (Вот ляпнул, да? - Без аргументов =), но на самом деле, я полагаю, так и есть). Это я узнал от одного знакомого программиста, который, в принципе, далеко не новичок в js (он писал псевдо-мультипоточность в js (сам по себе javascript - не мультипоточный язык (в полном понимании этого слова))). Информация мной лично - не проверена (чтобы утверждать, что js имеет именно два потока). Но, опять же повторю - думаю, так и есть (основной поток и поток setTimeout'a). Понимаю, аргумент очень не веский (какой-то там знакомый сказал), но - я видел, что он пишет и, в принципе, не сомневался в его словах (в частности, написан у его был класс Tread, который работал с потоком setTimeout'a - и большие нагруженные вещи выполнялись параллельно основной работе браузера (основного потока)). Вот в в этой теме я описывал эту мысль. А вообще, надо будет поискать эту тему подробней и пообсуждать.

Да я-то тоже узнаю все от одного программиста, далеко не новичка. Вот только он по этому поводу сказал бы, что-то вроде: "А нету, сынок, второго потока, как не ищи". 


Классы Thread не редкость, только авторы волей-неволей все же признают (Threading in JavaScript 1.7):




Хорошо бы - дополнительная информация не бывает лишней.

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


ну вот поэтому я и сказал "псевдо-"

Это сообщение отредактировал(а) dsCode - 24.9.2007, 12:27

cruelangel, 



alert(1) прорвется и будет вторым модальным окном наряду с alert(2) =) ну понятно, почему.

Да, можно сделать пока такие выводы: "второй поток" - метафора и понятие образное, "мультипоточность в js" - такое же образное понятие и идет с приставкой "псевдо".

Это сообщение отредактировал(а) dsCode - 24.9.2007, 13:11

это только в гекконах

Всем спасибо, значит setTimeout(), это метод объекта window. И не имеет значения, указывается window или нет, события происходят одинаковые. Понятно. А таймер,  понятие абстрактное, создано для удобства, на самом деле, подразумевается таймаут, параметры которого мы и задаем. Было бы странно возвращать идентификатор таймаута. 
А второй поток, наверное, ещё абстрактнее таймера, скорее в него отводят все процессы, которые сквозняком обращаются к функциям системы. В Windows ведь задаются таймеры, наверное они и используются для задания временных интервалов, и получается, что работают независимо от скрипта. А по окончании интервала заданного системному таймеру, происходит прерывание, по которому выполнение назначенной функции ставится первой в очереди команд, или там, ещё по каким правилам.

AKS, кстати, в той статье по ссылке - ориентация на версию 1.7 с ее yield, generator, iterator и прочими. Псево-мультипоточный класс Thread того человека, который мне говорил о "втором потоке" был написан еще два года назад, где еще не было ни yield, ни даже FF 2. Хотя, в сущности, это ничего не меняет - так, к слову. Вообще, предлагаю сделать отдельную тему, о "Псевдо-мультипоточности JS", где подробно описывать этот механизм, когда он может быть использован, какие нюансы и т.д.

---------------------------------------

P.S.: давайте вот такой код попробуем и объясним, почему window.a после выполнения основного потока (цикл for), который "подвешивает" браузер имеет уже значение 17, а не 0. Опять же - только в гекко, но все же. Значит значение вычислялось, пока работал цикл. Получается основной поток - прорисовывает окно, а во "втором" (нет никакой ложки) идет вычисление. Или вычислялось оно просто по истечению suspend'a, вклиниваясь в цикл?



-----------------------------------------------------------------------------

Updated:

ага, хрен оно вычисляется.



Но после этого - моментально выводит 30 значений, но "никаких 1000 миллисекунд". Это означает, что время suspend'a для функций setInreval'ов уже как бы "просроченно" и они моментально отрабатывают. Или как это более точно объяснить?

Это сообщение отредактировал(а) dsCode - 24.9.2007, 19:04

Я в прошлом году написал маленький скриптик для "снегопада". Для анимации каждой снежинки, которая должна была падать сверху вниз, раскачиваясь в стороны, создавался свой экземпляр конструктора. В прототипе конструктора имелось несколько функций, которые "управляли" снежинкой.  Одна из функций запускалась посредством метода window.setInterval. В результате получилось, что я "с дуру" для каждой снежинки установил свой интервал. Так вот, когда этих функций, выполняемых через заданные промежутки времени, создавалось слишком много (определялось кол-вом снежинок, например 60 штук), можно было наблюдать интересный эффект. Кстати, спасибо ksnk - он первый сообщил мне об этом. 
Эффект этот наблюдался только в Gecko, и заключался он в следующем. Когда браузер не успевал выполнить все функции вовремя, причем накапливалось их сразу несколько, то он (браузер FF) выполнял их тогда, когда у него освобождались ресурсы. Получалось, что снежинка, которая должна была через каждые 50 мс передвинуться на 2 px, передвигалась один раз в 2 с, но сразу на десяток пиксел. И так не с одной снежинкой (точнее, с функцией), а сразу со всеми. Очень смешной был эффект - браузер, как бы извиняясь, предлагал: "Ребят, я тут задержался малость, но сейчас все сходу наверстаю!". 
А IE и Opera выполняли себе стабильно через те промежутки времени, которых им хватало на обработку функций, вызванных ранее.
Происходит это потому, что в Gecko есть такая фишка. Браузер высчитывает время задержки, если таковая случилась, и видимо где-то там в своих "поторохах" сохраняет для вот таких вот описанных выше "эффектов", т.е. вычесть эту задержку из имеющегося интервала, чтобы "нагнать упущенное". Кстати, это время задержки передается первым аргументом в функцию, которая в свою очередь была передана методам setTimeout/setInterval (на это мне Zeroglif открыл глаза, показав где об этом прочесть). Вот пример для удобства:

Функция в setTimeout выполнится не через полсекунды, а тогда, когда для нее появится время, и время задержки будет передано первым параметром (будет около 1500 мс). Видимо, это и вычитается из заданных задержек.
Вот такой он, этот Gecko...

Это сообщение отредактировал(а) AKS - 24.9.2007, 19:10

по этой причине я отказался от использования setInterval в пользу такой вот загогулины:



Это сообщение отредактировал(а) cruelangel - 24.9.2007, 20:49

Ну вот и я о том же. Тогда, почти год назад, ksnk показал, что лучше всего все функции, какие должны вызываться через определенные промежутки времени (в данный момент пишу о случае с одинаковыми интервалами), "совать" в одну, и только ее одну передавать в setInterval. Техника может быть такой. В какой-то момент вызывается метод window.setInterval. Функция, которая ему передается, пробегает по массиву с функциями и вызывает их все. В это время в массив могут быть добавлены/удалены функции, которые выполнили свою задачу. Если в массиве функций не осталось, то делается window.clearInterval. Ничего себе так экономия получается...