Canon rilancia: ecco la 550D

Re: Si scoprono gli altarini
- Scritto da: FDG
- Scritto da: nexor

Dal punto di vista dell'utente non cambia nulla
se il proXXXXX viene chiuso o riaperto (è un
requisito del software per iPhone che debba
registrare lo stato) o se viene messo in
background. È importante quanto tempo impiega per
passare da un'applicazione all'altra. Cioè è un
mero problema d'interfaccia. Basterebbe, ad
esempio, rendere più facili da raggiungere le
ultime applicazioni aperte. Anzi, i concetti di
"apertura" e "chiusura" dell'applicazione
dovrebbero
sparire.Invece cambia eccome: le applicazioni in background non devono per forza essere inattive: lettori musicali, instant messenger, geo-localizzazione, browser di vario tipo (tanto per fare degli esempi) devono continuare ad elaborare e mantenere connessioni attive anche in secondo piano, è questo il vantaggio principale del multitasking, non basta passare rapidamente tra le applicazioni, come invece può avvenire su iPhone.Non credo che per applicazioni come quelle sopracitate possa bastare un palliativo come le push notifications o un sistema a callback: complicazioni eccessive se in alternativa è possibile una gestione completa del multitasking.

Immagino tu non abbia mai avuto occasione di

programmare un'applicazione multithreading

Invece si


completa: se si crea un proXXXXX (thread) ci
deve

essere un motivo, perché usarli e gestire la

concorrenza non è per niente semplice ed è una

perenne fonte di bug.

In questo specifico caso bisogna solo definire
handler di messaggi. Gli handler devono essere in
un unico proXXXXX verso cui le richieste devono
essere accodate dal sistema in modo che siano
processate una alla volta. È un modello chiaro e
facile da gestire. Lavoro con questo modello da
anni in un contesto totalmente differente
(client/server) e non ho mai avuto problemi di
concorrenza.Beh, se stai parlando di sistemi transazionali mi pare un paradigma inapplicabile, può andar bene per ambiti molto specifici, è tutto più facile se le possibilità sono limitate, ma nella normale programmazione si procede ad un livello di astrazione superiore, il che rende tutto più semplice, quindi migliore! Usando un handler, si delega ad esso la gestione di concorrenza ed acXXXXX alle risorse, ma questo è esattamente ciò che deve fare un SO, se non lo fa bene è colpa sua. Se l'utilità invece stesse nel ridurre il carico del proXXXXXre, il fatto è che se le operazioni da eseguire perché l'applicazione svolga il suo compito sono quelle, che le esegua un thread di sistema o uno dell'applicazione non dovrebbero variare.Inoltre gli insiemi di dati su cui operano applicazioni differenti, in un sistema multitasking, sono quasi completamente separati, e possono raggiungere dimensioni e complessità notevoli. Vanno inizializzati all'avvio di un'applicazione, e mantenuti in memoria volatile, anche usando un sistema di callback, in genere caricarli al volo non lo vedo fattibile, e qui tra handler e thread dedicati non ci sono differenze.
Chiaramente parlavo di thread attivi. Visto che
purtroppo c'è parecchio software scritto con i
piedi che inspiegabilmente incomincia a consumare
il tempo del proXXXXXre rallentandoti tutto il
sistema quando non è usato
dall'utenteE' qui che si rendono utili strumenti come il profiler della nokia che citavo. Credo che Apple invece abbia scelto di semplificare tutto al massimo per i programmatori, tralasciando queste problematiche. In questo modo ha puntato tutto sulla quantità e varietà della propria offerta di software, tralasciando la qualità: strategia vincente, si è visto, ma che ha i propri limiti. MS viceversa non credo abbia questa mancanza di sviluppatori, dovrebbe concentrarsi su qualità del software e fruibilità, ma forse è ormai troppo tardi e difficile, e preferisce ripiegare sulla semplificazione forzata, come parrebbe da questa notizia.

, e molto ma molto poca in genere: è in

gran parte condivisa tra thread, è la differenza

tra thread e proXXXXX...

Applicazioni differenti sono processi differenti,
non thread. Qui purtroppo si parla di
applicazioni differenti una in foreground e le
altre in
background.Sisi, non so perché stavo un po' divagando...

Ovviamente questo se

tutto va bene, c'è sempre software di scarsa

fattura che si comporta male,

Infatti. Per questo definire precisi
comportamenti che può mantenere il software
attraverso vincoli stabiliti dal modello di
programmazione, cioè dalle API di sistema (o
dalle classi del framework) può restringere il
campo d'azione degli Unni della programmazione
:-) Ma rischia anche di farli impazzire, o bloccarli del tutto, secondo me.

ma quello che

voglio dire è che non c'è bisogno di

rivoluzionare il modello di programmazione

multitasking

Io penso che su un mondo nuovo come quello degli
smartphone (sistemi nuovi, software nuovo) si
possa adottare. Non è detto che si riesca a
trasferire questo modello al mondo desktop, anche
se ho buoni motivi per desiderare che sia così:
semplicemente mi sono stufato del software che
rompe le scatole quando non
dovrebbe.Invece secondo me software che funziona bene ce n'è già, il problema è che l'evoluzione del software è molto più lenta di quella dell'hardware che gli sta sotto, semplicemente perché si tratta di un ambito sconfinato. Se però almeno nel mondo mobile la situazione si mantiene come quella attuale, cioè di concorrenza spietata, le cose non potranno che migliorare!