windows - hvorfor forsøger at åbne en topen dialog gyning et ton af tråde?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har fået en meget enkel form med en TopenDialog og en knap på den. Når jeg trykker på knappen, kalder den Execute på dialogboksen. Hvis jeg ser i debuggeren, åbner åbningen af ​​dialogboksen noget som 14 tråde, og de går ikke væk, når jeg lukker dialogboksen heller.


Nogen har nogen ide om, hvad der foregår med det?

Bedste reference


Forestil dig at du vil vise dine venner, hvor smukke Pacific Northwest er. Du beslutter dig for at tage afsted på en tur for at få et par fotos af solnedgang over Stillehavet. Hvad du virkelig er interesseret i, er billedfilerne der kommer hjem, hvor de kan uploades til Facebook. I virkeligheden skal kameraet, linserne og stativet trækkes over OL og tilbage. Du skal også bringe fotografen (dig selv), som vil sætte kameraet op og trykke lukkeren. Fotografen skal flyttes der og tilbage i relativ komfort, så du tager plads, hvor fotografen vil hvile, mens du gør rejsen. Dette sæde er omsluttet i en blank metalboks med en masse andre metal-, glas- og gummidele, hvoraf nogle drejer og går frem og tilbage. I sidste ende tager omkring to tons ting (og et levende menneske) en tur på flere timer, brændende galloner kulbrintevæske - med det formål at flytte et par stykker information fra kysten til internettet.]] [2]


Præcis det samme sker med din ansøgning. Når brugeren ønsker at åbne en fil ved hjælp af dialogboksen 'Åbn fil', forventer brugeren at kunne:



  • Naviger til mappen, der indeholder filen (mappen kan være på lokal harddisk eller cd/dvd/BR eller netværksdrev eller arkiv osv. Mediet kan være krypteret eller komprimeret, hvilket skal vises forskelligt. kan ikke være tilsluttet, som brugeren muligvis skal anmodes om. Mediet kan kræve brugerens legitimationsoplysninger, som skal stilles);

  • Opret forbindelse til en ny mappe ved hjælp af dens URI/UNC (kortlæg drevet);

  • Søg i mappen for nogle søgeord;

  • kopiere/slette/omdøbe nogle filer;

  • Se listen over filerne i den pågældende mappe;

  • Forhåndsvis indholdet af hver fil i mappen;

  • vælg hvilken fil der skal åbnes;

  • ændre hans/hendes sind og beslutter ikke at åbne filen;

  • gør mange andre filrelaterede ting.



OS gør det muligt at gøre alt ved at give din proces det meste af Windows Explorer-funktionaliteten. Og noget af det skal ske i baggrunden, ellers vil brugerne klage over, hvordan man ikke reagerer på Open File-dialogen. Den indlysende måde at køre nogle opgaver i baggrunden på er at køre dem på forskellige tråde. Så det er det vi ser.


Hvad med trådene bagved, spørger du? Nå, nogle af dem er der tilbage, hvis brugeren beslutter at åbne en anden fil: det sparer meget tid, trafik og skrivning i dette tilfælde. Den brugerdefinerede godkendelse bruges til denne ene proces sidste gang? - gemt Forhåndsvisning ikoner til de irriterende PDF-filer? -- stadig her. Længden og bithastigheden for hver film i mappen? - stadig tilgængelig, ingen grund til at parse dem igen.


Selvfølgelig viste trådene ikke kun magisk ud af sig selv. Tjek, hvor mange DLL'er der er blevet kortlagt i processen. Kig på nogle af dem kan man få et ganske interessant billede af, hvilken funktionalitet der er blevet tilføjet.


En anden interessant måde at se på det ville være at dumpe callstacks i øjeblikket hver tråd bliver skabt. Dette viser, hvilken DLL (og undertiden hvilken genstand) der er skabt dem. Her er hvordan en x64 Win7 opretter alle trådene. Man kan finde, at Explorer-rammens tråd bliver skabt; nogle OLE-aktiviteter, som vil blive brugt til at instantiere filfiltre, hvoraf nogle kan generere forhåndsvisningsikoner, overlejringer og værktøjstips; Få tråde tilhørende søgesystemet shell-enhedens opregner (så hvis brugeren plugger i en ny enhed, vises den automatisk i den åbne dialog), shell-netværksmonitor (ditto) og andre ting. [3]


Den gode nyhed er, at det sker hurtigt og ikke tilføjer for meget til din proces. De fleste af trådene bruger det meste af tiden og venter på nogle sjældne hændelser (som USB-nøgle er tilsluttet), så CPU'en bruger ikke nogen tid at udføre dem. Hver tråd forbruger 1 MB virtuelt adresserum i din proces, men kun få 4 kb sider med faktisk fysisk hukommelse. Og de fleste, hvis ikke alle disse DLL'er ikke brugte nogen diskbåndbredde, der skal læses: de var allerede i RAM, så de blev lige kortlagt i din proces for næsten gratis.


I sidste ende fik brugeren en hel del brugbar funktionalitet i et snappy brugergrænseflad, mens processen skulle gøre meget lidt for at opnå alt det.