Dnia Fri, 01 Feb 2013 11:33:33 +0100, Cezary Tomczyk napisał(a):

>> priorytetem funkcji jest wykonać się w określonym czasie, nie określoną
>> liczbę razy, co w razie problemów z kodem może się dowolnie przeciągnąć.
>
> Jeśli akcja B zależy od wyniku akcji A (i tak w kolko), a akcja A
> zamiast wykonać się w 100ms wykona się w 200ms, to w międzyczasie akcja
> B uruchomi się i będzie błąd, gdyż nie ma jeszcze wyniku z akcji A.
> Czemu właśnie przeciwdziała setTimeout.

A masz taki przypadek przy zwykłym animowaniu? To z reguły regularne
modyfikowanie określonych wartości, niezależnych od siebie, z ew.
wywołaniem zdarzenia na sam koniec. Zaś napisanie kodu w powyższy sposób to
wręcz podręcznikowe race condition :)

>> Co do #1 to mam mieszane uczucia - daje to jednak pewność, że kod będzie
>> się wykonywać aż do czasu wyłączenia timera.
>
> O ile chcemy by się wykonywał aż do czasu wyłączenia timera.

Owszem - dlatego zapewne powstały te dwie, uzupełniające się funkcje. Zaś
autor artykułu napisał go pod swoje potrzeby, ktore spełnia setTimeout() :)

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 2013-02-01 20:28, Borys Pogoreło pisze:
>> Jeśli akcja B zależy od wyniku akcji A (i tak w kolko), a akcja A
>> >zamiast wykonać się w 100ms wykona się w 200ms, to w międzyczasie akcja
>> >B uruchomi się i będzie błąd, gdyż nie ma jeszcze wyniku z akcji A.
>> >Czemu właśnie przeciwdziała setTimeout.
> A masz taki przypadek przy zwykłym animowaniu? To z reguły regularne
> modyfikowanie określonych wartości, niezależnych od siebie, z ew.
> wywołaniem zdarzenia na sam koniec. Zaś napisanie kodu w powyższy sposób to
> wręcz podręcznikowe race condition :)
>

brawo geniusze, brawo.
Szkoda tylko, że JS jest wykonywany w jednym wątku...

do góry

W dniu 2013-02-01 16:36, Marek pisze:
> Sprawdzałeś dla 10mS?

Może zacznijmy od tego, że wszelkie wartości poniżej 17ms są czystym
kretynizmem.

do góry

Dnia Fri, 01 Feb 2013 21:23:58 +0100, Jasio napisał(a):

>>> Jeśli akcja B zależy od wyniku akcji A (i tak w kolko), a akcja A
>>> >zamiast wykonać się w 100ms wykona się w 200ms, to w międzyczasie akcja
>>> >B uruchomi się i będzie błąd, gdyż nie ma jeszcze wyniku z akcji A.
>>> >Czemu właśnie przeciwdziała setTimeout.
>> A masz taki przypadek przy zwykłym animowaniu? To z reguły regularne
>> modyfikowanie określonych wartości, niezależnych od siebie, z ew.
>> wywołaniem zdarzenia na sam koniec. Zaś napisanie kodu w powyższy sposób to
>> wręcz podręcznikowe race condition :)
>
> brawo geniusze, brawo.
> Szkoda tylko, że JS jest wykonywany w jednym wątku...

W międzyczasie sprawdzaj, komu odpisujesz.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

Dnia Fri, 01 Feb 2013 21:23:58 +0100, Jasio napisał(a):

>>> Jeśli akcja B zależy od wyniku akcji A (i tak w kolko), a akcja A
>>> >zamiast wykonać się w 100ms wykona się w 200ms, to w międzyczasie akcja
>>> >B uruchomi się i będzie błąd, gdyż nie ma jeszcze wyniku z akcji A.
>>> >Czemu właśnie przeciwdziała setTimeout.
>> A masz taki przypadek przy zwykłym animowaniu? To z reguły regularne
>> modyfikowanie określonych wartości, niezależnych od siebie, z ew.
>> wywołaniem zdarzenia na sam koniec. Zaś napisanie kodu w powyższy sposób to
>> wręcz podręcznikowe race condition :)
>
> brawo geniusze, brawo.
> Szkoda tylko, że JS jest wykonywany w jednym wątku...

Jak już ogarniesz asynchroniczne wywołania, które oprogramowane *w ten
sposób* można doprowadzić do wyścigu, to wróć, pogadamy.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 2013-02-01 22:52, Borys Pogoreło pisze:
> W międzyczasie sprawdzaj, komu odpisujesz.

Tobie i Tomczykowi, bo obaj bredzicie.

do góry

W dniu 2013-02-01 22:58, Borys Pogoreło pisze:
> Jak już ogarniesz asynchroniczne wywołania, które oprogramowane *w ten
> sposób* można doprowadzić do wyścigu, to wróć, pogadamy.

Po pierwsze wytłumacz mi co ma race condition do środowiska ST, jakim
jest JS, skoro to problem, który pochodzi z MT???
Jak możesz mieć race condition z *jednego* wątku???

Tomczyk pisze "to w międzyczasie akcja B uruchomi się i będzie błąd,
gdyż nie ma jeszcze wyniku z akcji A"
a Ty mu odpowiadasz:
"A masz taki przypadek przy zwykłym animowaniu?"

Czyli obaj uważacie, że coś takiego jest możliwe, ale coś takiego nigdy
się nie wydarzy w JS, bo to jest single thread!!!

setTimeout(function() {while(true) {} }, 4);
setTimeout(function() {alert('as'); }, 5);

w tym przypadku alert nie wykona się nigdy, bo pierwsza funkcja będzie
trwała w nieskończoność, a powtórzę po raz kolejny: w JS nie ma MT (nie
licząc Workerów, ale nie o tym mowa, bo one z tego powodu nie mają
dostępu do DOM)!!!

setInterval(function() {for(i=0;i<N;i++) {}}, 4)

Tutaj jeśli podstawisz odpowiednio duże N, tak żeby for wykonywał się
równo minutę, to po 10 minutach będzie równo 10 wywołań funkcji, bo
kolejne wywołanie nie zostanie wykonane, dopóki pierwsze się nie
skończy, czyli *NIGDY* nie będziesz miał dwóch funkcji wykonujących się
równocześnie, a co za tym idzie, nie istnieje problem, o którym tak
namiętnie dyskutujecie!

do góry

W dniu 2013-02-02 00:30, Jasio pisze:
> W dniu 2013-02-01 22:52, Borys Pogoreło pisze:
>> W międzyczasie sprawdzaj, komu odpisujesz.
>
> Tobie i Tomczykowi, bo obaj bredzicie.

Możesz jaśniej?

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

W dniu 2013-02-02 01:09, Cezary Tomczyk pisze:
> W dniu 2013-02-02 00:30, Jasio pisze:
>> W dniu 2013-02-01 22:52, Borys Pogoreło pisze:
>>> W międzyczasie sprawdzaj, komu odpisujesz.
>>
>> Tobie i Tomczykowi, bo obaj bredzicie.
>
> Możesz jaśniej?
>

Przeczytaj 2 posty wyżej/niżej.

do góry

W dniu 2013-02-02 00:32, Jasio pisze:
[...]nie istnieje problem, o którym tak
> namiętnie dyskutujecie!

Uh, ale są inne problemy:

https://developer.mozilla.org/en-US/docs/DOM/window.
setInterval#Dangerous_usage

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry