В общем то, вопрос в названии.
Я так понимаю, что если запускать таймаут таким образом "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. Ничего себе так экономия получается...

AKS, 

да, это я уже заметил в предыдущем посте (там, где updated). За пример - спасибо. Действительно, такой параметр приходит, причем первым, - и только в FF. Для IE и Opera - undefined.


покажите и мне, если не затруднит =) тоже интересно )


не совсем понятно. Такое ощущение, что IE и Опере по-барабану на это "упущенное время", они "тупо" начинают выполнять setInterval'ы и setTimeout'ы после "освобождения ресурсов", потому что и в IE и в Опере - отсчет начинался с 0 - "согласно расписанию", а в FF - тоже с 0 (а не с 17, как выяснилось в моей последней поправке), но - с "учетом потерянного времени", которое, как оказалось - передалось первым параметром! Хм... +1.

Добавлено через 13 минут и 10 секунд

а что насчет неодинаковых интервалов?

Да чего же тут трудного , пожалуйста - Creating time delays.

А что, так и есть. Выполняют код, когда движок освободится (он же single-threaded как-никак).


Да незнаю пока - не сталкивался...


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

Другая ссылка про lateness.
И ещё.
И ещё.

Правда, на мой взгляд это никак не объясняет поведение setInterval в коде dsCode.

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

использование window.setTimeout - это как-то не в ооп стиле  для полноты картины предлагаю использовать:

var func= function( ){ alert( 1 ) };
window.exec( func );

Вот как-раз, чтобы поправить вот это:

Не обязательно первым, а первым "свободным индексом" в объекте аргументов.



window.execScript может быть? А как им заменить window.setTimeout?


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

window.exec= function( func ){
    return func( );
}

 заменить, конечно не сможет, зато запуск функции с задержкой и без оной будут производиться однотипно - через window

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

Вот только хотел спросить: как эта задержка может быть отрицательной? Я добавил в пример dsCode вывод arguments[0] - если для первой итерации она составляет порядка 8000 мс, то к 15-й при некоторых запусках постепенно уменьшается до отрицательной величины -4000 - -6000. Далее, по идее, должен идти штатный режим, но и при нем задержка то колеблется в пределах ±15 мс около нуля, а то... около -1000. Получается, что таймер "заодно" выполняет и следующую итерацию - ради оптимизации рендеринга, что ли? Или это артефакт? Как объяснить эту странность?

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

Получается, что таймер ждёт, когда откроется форточка, чтобы в неё влезть, но, если в IE до её открытия в очереди стоит всего одно "переждавшее" действие, то в FF - все "переждавшие" по времени к моменту открытия форточки. Поэтому к выходу из loop-а никто ничего ещё не сделал, но уже приготовился сделать - IE приготовился изменить innerHTML(IE) один раз, FF несколько раз подряд. Так примитивно выглядит со стороны (найти бы того, кто почитает код симанки...).

Вот ещё странности со сдвоенными setInterval, там же очередная ссылка на багзилу.

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

don't know

Это их глюк. У них же там бардак полнейший! Вот, например из ссылок Zeroglif'а, первый рапорт об аргументе с задержкой датирован 1999 годом. Пишут: "Надо бы сделать одно из двух - убрать эту отладочную ин-фу, или хотя бы задокументировать". Потом, 2004 год: "Посмотрели, поискали - оказалось, что до сих пор не задокументировали". С интервальными глюками, так вообще - полгода писали-писали другу другу, в конце концов Брендан: "Кто-нибудь займитесь этим глюком - у меня нету времени!". Ну вот и занимаются до сих пор... 
Короче говоря, то ли для них это серьезная проблема, что решить никак не могут, то ли просто плюнули на это все. А что вообще ждать от бесплатного софта? 
В этом плане IE, все эти годы работая без подобных проблем, и уже, как многие считают, находясь в "преклонном возрасте", выглядит молодцом. Честь и хвала разработчикам IE, которые написали такой стабильный в этом плане движок!

// Leave an extra slot for a secret final argument that
// indicates to the called function how "late" the timeout is.

хакеры, блин Ж-)


> Честь и хвала разработчикам IE, которые написали такой стабильный в этом плане движок! 

в каком плане?

Это сообщение отредактировал(а) cruelangel - 25.9.2007, 11:03

cruelangel, в каком плане? Специально дошел до тавтологии, да еще и выделил курсивом, чтобы акцентировать мысль на том, что обсуждалось. Поясню.
Всем этим "недоразумения" с Gecko'вским поведением в плане setInterval, я решил противопоставить IE'шную стабильность. Просто IE никогда не давал мне повода беспокоиться о том, что в каком-нибудь dhtml у меня появятся явные проблемы, вроде "тормозов" или "аритмии", ну или еще чего. Вот за это и спасибо разрабам IE.

Мне, на самом деле, без разницы - IE, Gecko, Opera. Просто на форумах большинство "балдеет" от FF, незабывая "пнуть" IE. "Текут слюни и сопли" от современных "классных" возможностей FF, при этом народ не знает, что есть "копнуть" FF, то окажется, что "нутро гниловато" - древнейшие баги не исправлены. 
У всех, конечно же, свои недостатки. Но есть и отлично реализованные возможности. Почему бы об этом не сказать пару добрых слов? Даже в адрес не "модного" браузера...

Это сообщение отредактировал(а) AKS - 25.9.2007, 14:11

А я IE люблю,  для людей сделан, а не для программистов.  

Не примите смайлик на свой счет...  

Это сообщение отредактировал(а) Ghirik - 25.9.2007, 14:37

и в чём же тут баг? вполне логичное поведение. если задал период в 1 секунду - получи 10 срабатываний за 10 секунд. если разработчик написал функцию, которая за эту секунду не успевает отработать - получай тормоза.



Это сообщение отредактировал(а) cruelangel - 25.9.2007, 17:35

В основном речь идет о работе с веб-документом, а в нем много всяких событий происходит. Эти события могут стать причиной задержки выполнения "задуманного"...

поэтому делать надо с запасом. большим. 

С "большим запасом"? Это, к примеру, для изменения прозрачности изображений установить интервал в одну, а то и в две секунды - вот будет спецэффект! 
А главное - в Gecko не будет "тормозов"! 

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


Это сообщение отредактировал(а) cruelangel - 26.9.2007, 12:46

cruelangel
1. Ради Gecko чего только не сделаешь. 
2. Какие критерии оценки "нужна/не нужна анимация".

1. геккон тут не при чём. это простая и эффективная защита от возможных наслоений.
2. когда она ничем не обоснована - она не нужна.