Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

web workers

5 views
Skip to first unread message

scootergrisen

unread,
Jul 28, 2012, 2:00:55 PM7/28/12
to
Er der nogen af jer der ved noget om web workers ?

Jeg har den her test som jeg gerne vil lave om til at bruge web workers :
http://scootergrisen.dk/htmlgrisen/eksempler/eksempel0008.html

Men window objektet er ikke tilg�ngeligt for en web worker s� hvordan
skal man lave det ?

Det var meningen jeg ville kalde localStorage.setItem('', e.data); fra
min web worker fil men det er ikke tilladt da window objektet ikke er
tilg�ngeligt.

Anders Wegge Keller

unread,
Jul 28, 2012, 4:44:16 PM7/28/12
to
scootergrisen <NEJ...@TILSPAM.DK> writes:

> Er der nogen af jer der ved noget om web workers ?
>
> Jeg har den her test som jeg gerne vil lave om til at bruge web workers :
> http://scootergrisen.dk/htmlgrisen/eksempler/eksempel0008.html
>
> Men window objektet er ikke tilgængeligt for en web worker så hvordan
> skal man lave det ?

Kan du bruge wikipedias eksempel til noget?

<http://en.wikipedia.org/wiki/Web_worker#Example>

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

B�rge Jensen

unread,
Jul 28, 2012, 5:25:34 PM7/28/12
to
scootergrisen wrote:

> Er der nogen af jer der ved noget om web workers ?

Nej, hvad er det, fort�l noget mere om det!

--
B�rge Jensen


scootergrisen

unread,
Jul 28, 2012, 6:37:40 PM7/28/12
to
> Kan du bruge wikipedias eksempel til noget?
>
> <http://en.wikipedia.org/wiki/Web_worker#Example>

Ikke rigtig.

scootergrisen

unread,
Jul 28, 2012, 6:38:06 PM7/28/12
to
>> Er der nogen af jer der ved noget om web workers ?
>
> Nej, hvad er det, fortæl noget mere om det!

Jeg er lige gået igang med det så ved ikke rigtig noget om det.

Anders Wegge Keller

unread,
Jul 28, 2012, 7:01:30 PM7/28/12
to
OK, det lader nu ellers til at være rimeligt letfatteligt.

Der er *en* forbindelse mellem din webworker og browservinduet. Det
er postmessage(). I din main session skal du have en eventhandler på
onmessage eventen på dit Worker object. Når du kalder postmessage()
fra din worker, får eventhandleren et event med de data din worker har
sendt afsted.

Din eventhandler, der kører i din main session, har adgang til
window, og derfra kan du så fylde resultaterne på, efterhånden som de
indløber.

scootergrisen

unread,
Jul 28, 2012, 7:03:56 PM7/28/12
to
> Din eventhandler, der kører i din main session, har adgang til
> window, og derfra kan du så fylde resultaterne på, efterhånden som de
> indløber.

Ja men jeg ville egentligt gerne have setItem() i min web worker fil da
jeg regner med det er den som udfører det arbejde som tager længst tid
men det kan jeg jo ikke.

Anders Wegge Keller

unread,
Jul 28, 2012, 7:38:43 PM7/28/12
to
Ja, så er du lidt på spanden :( Jeg har kun lige skimmet
specifikationen, så jeg ved ikke om du kan få et brugbart resultat ud
af at sende en reference til window gennem postMessage(). Hvis du ikke
kan det, har jeg et andet forslag:

Skriv check() om, så den kun prøver en (eller et begrænset antal)
datastørrelser for hvert kald, og "kald" den med setInterval(check,
100). I starten af check() kalder du så clearInterval(), og afslutter
med et fornyet kald til setInterval(check,100). På den måde undgår du
at låse browseren.

Dit reelle problem er et helt andet sted, nemlig her:

for(var i=1; i<=blablaantal; i++){
data += 'x';
}

Det er noget nær den mest ineffektive måde at lave en streng af en
bestemt længde på, da browseren skal lave en ny streng hver gang du
bruger +=. Det vil være noget bedre kun at allokere en streng:

data = new Array(blablaantal).toString();

Mit gæt er at det giver dig så meget performanceforbedring, at du
slipper for at tænke på web workers og andet.

scootergrisen

unread,
Jul 28, 2012, 10:48:36 PM7/28/12
to
> Ja, så er du lidt på spanden :( Jeg har kun lige skimmet
> specifikationen, så jeg ved ikke om du kan få et brugbart resultat ud
> af at sende en reference til window gennem postMessage(). Hvis du ikke
> kan det, har jeg et andet forslag:
>
> Skriv check() om, så den kun prøver en (eller et begrænset antal)
> datastørrelser for hvert kald, og "kald" den med setInterval(check,
> 100). I starten af check() kalder du så clearInterval(), og afslutter
> med et fornyet kald til setInterval(check,100). På den måde undgår du
> at låse browseren.

Jeg havde også sådan noget med interval i starten men det er jo også
dårligt fordi så forsinker man med vilje opgaven.

> Dit reelle problem er et helt andet sted, nemlig her:
>
> for(var i=1; i<=blablaantal; i++){
> data += 'x';
> }
>
> Det er noget nær den mest ineffektive måde at lave en streng af en
> bestemt længde på, da browseren skal lave en ny streng hver gang du
> bruger +=. Det vil være noget bedre kun at allokere en streng:
>
> data = new Array(blablaantal).toString();
>
> Mit gæt er at det giver dig så meget performanceforbedring, at du
> slipper for at tænke på web workers og andet.

Jeg er ik lige så skarp til javascript så derfor er alt koden ikke så god.

Jeg prøver og se hvordan det går men det.

Der er også noget med join() er det bedre at bruge ?

Stig Johansen

unread,
Jul 30, 2012, 2:36:06 AM7/30/12
to
B�rge Jensen wrote:

> scootergrisen wrote:
>
>> Er der nogen af jer der ved noget om web workers ?
>
> Nej, hvad er det, fort�l noget mere om det!

Der er (fors�g p�?) implementering af multithreading.

L�s Wegges link, som er meget beskrivende.

At bruge message handling er dog ikke �gte(preemtive multitaksing), men det
samme som Win3-3.11 (cooperative multitasking).

Hvad man skal bruge det til, og hvorvidt det bliver brugbart m� tiden vise,
for der er det s�dvanlige problem med 'synkronisering' af ejerskab af de
visuelle objecter (aka DOM).

Hvad skal det bruges til? - dvs. Hvilek lonh running tasks har du (OP)?

--
Med venlig hilsen
Stig Johansen

scootergrisen

unread,
Jul 30, 2012, 8:11:04 AM7/30/12
to
> Hvad skal det bruges til? - dvs. Hvilek lonh running tasks har du (OP)?

St�r i min f�rste tr�d.

Stig Johansen

unread,
Jul 31, 2012, 2:33:52 AM7/31/12
to
scootergrisen wrote:

>> Hvad skal det bruges til? - dvs. Hvilek lonh running tasks har du (OP)?
>
> St�r i min f�rste tr�d.

Det har jeg skam l�st, men det kan du ikke bruge til en hujende fis.

Hvis du gerne vil give et memory overflow til dine brugere er det langt
lettere og hurtigere at bruge:
http://docstore.mik.ua/orelly/webprog/jscript/ch09_01.htm

Med en bin�r approach kan du k�re det p� h�jst 64 iterationer (eller 32).

scootergrisen

unread,
Jul 31, 2012, 7:58:21 AM7/31/12
to
> Det har jeg skam l�st, men det kan du ikke bruge til en hujende fis.
>
> Hvis du gerne vil give et memory overflow til dine brugere er det langt
> lettere og hurtigere at bruge:
> http://docstore.mik.ua/orelly/webprog/jscript/ch09_01.htm
>
> Med en bin�r approach kan du k�re det p� h�jst 64 iterationer (eller 32).

Jeg ved ikke rigtig hvad du snakker om jeg er ikke s� god til javascript.

scootergrisen

unread,
Jul 31, 2012, 7:59:06 AM7/31/12
to
Nu har jeg f�et hj�lp til nogen til at g�re det p� en anden m�de uden
web workers.

http://scootergrisen.dk/test/test0154.html

Det virker ikke helt godt endnu men hvis i har nogen kommentar til koden
s� kom gerne med det.

Stig Johansen

unread,
Aug 1, 2012, 2:07:27 AM8/1/12
to
Jeg forst�r stadug ikke helt form�let, men det er din sag.

Det man skal have in mente mht. Java(script),C# osv. er GC (Garbage
Collector).

N�r du k�rer 'nede fra og op', er der ingen garanti for at de tidligere
allokerede strenge/objekter rent faktisk (fysisk) er frigivet, og derfor
vil du aldrig f� et p�lideligt resultat.

Du skal lave en konstruktion ala (pseudo kode):
try
alloker 2^64 bit
catch
pr�v med mindre
until ok.

scootergrisen

unread,
Aug 1, 2012, 10:49:18 AM8/1/12
to
Det er ogs� det jeg g�r i koden.

try {
localStorage.setItem(key, buffer);
} catch(e) {
console.log('Unable to store buffer');
}

Stig Johansen

unread,
Aug 2, 2012, 2:43:22 AM8/2/12
to
scootergrisen wrote:

>> Du skal lave en konstruktion ala (pseudo kode):
>> try
>> alloker 2^64 bit
>> catch
>> pr�v med mindre
>> until ok.
>>
>
> Det er ogs� det jeg g�r i koden.
>
> try {
> localStorage.setItem(key, buffer);
> } catch(e) {
> console.log('Unable to store buffer');
> }

Nej du g�r ikke.

Du fylder memory nedefra og op, i stedet for at tjekke oppefra og ned.

Jeg kan stadig ikke forst� hvad du vil bruge det til, udover at l�gge
brugerens maskine ned.

Pr�v nu at s�tte dig lidt ind i programmering hvis du vil lege med p� den
boldgade.

Du fik nogle indirekte hints:
1) P� 32 bit OS'er er max gr�nsen 2^32 bit.
2) P� 64 bit OS'er er max gr�nsen 2^64 bit.

Det kan vel ikke v�re s� sv�rt at forst�..?

Nu t�nker du nok p� fysisk memory, men s� skal du ogs� s�tte dig ind i
virtuel memory.

N�R du har sat dig ind i disse begreber kan du muligvis forst� hvad der
foreg�r i en computer/OS.
0 new messages