[Gfoss] R: Rilascio MapStore 1.5.1 con versione Mobile per Android

a.furieri a lqt.it a.furieri a lqt.it
Lun 24 Mar 2014 16:12:53 CET


Ciao Strk,

On Mon, 24 Mar 2014 13:55:13 +0100, Sandro Santilli wrote:
>>   giusto per semplificare la vita, non e' invece thread-safe la
>>   gestione dei messaggi di errore, a meno di non avventurarsi in
>>   soluzioni abbastanza "creative/fantasiose" (come quelle poi
>>   adottate da splite).
>
> Mi rinfreschi la memoria ?
> I messaggi di errore vengono passati alla funzione che fornisci
> con il "contesto" GEOS, dove fallisce la thread-safety ? Non puo'
> essere che all'esterno di GEOS...
>

sorry, mi sono purtroppo espresso in modo frettoloso e poco preciso.
non c'e' nulla nella gestione degli errori che offenda la sicurezza
dei theads, funziona perfettamente bene.
e' semplicemente molto poco pratico da usare; e vediamo perche':

extern GEOSMessageHandler GEOS_DLL
     GEOSContext_setErrorHandler_r(GEOSContextHandle_t extHandle,
                                   GEOSMessageHandler nf);

fino a qua tutto perfetto; passi un context diverso per ciascun
thread, e tutto va perfettamente a posto.
poi pero' passiamo a vedere il prototipo della funzione handler
che viene chiamata in callback:

typedef void (*GEOSMessageHandler)(const char *fmt, ...);

dov'e' il problema ?
non appare mai da nessuna parte il riferimento al context che
ha dato origine all'errore; cosi' come non e' possibile gestire
un qualunque pointer "custom"
e quindi diventa abbastanza complicato tracciare a ritroso
la causa scatenante dell'errore.

molte altre librerie (libxml2, libproj, ma anche la stessa
libsqlite3) quando devono affrontare problemi analoghi
consentono sempre di passare avanti ed indietro un generico
pointer void * fornito dal chiamante, su cui la funzione
chiamata evita accuratamente di ficcare il becco limitandosi
semplicemente a propagarlo tal quale a tutte le chiamate
callback.

una soluzione di questo tipo e' flessibile al massimo, e
consente facilmente al codice chiamante di mettere in piedi
con minimo sforzo tutte le diavolerie possibili per tenersi
le cose ben allineate e chiaramante tracciate per origine.
con la soluzione GEOS questo diventa invece un po' piu'
incasinato; tutto qua.

alla fine per splite ho risolto prevedendo un numero massimo
di contexts possibili, ed ho associato una funzione handler
diversa per ciascun context; in questo modo si riesce a
tracciare individualmete ciascun contesto senza violare
la thread-safety.
funziona perfettamente: ma comunque e' una soluzione
"barocchetta/roccoco'"


On Mon, 24 Mar 2014 13:42:19 +0100, Sandro Santilli wrote:
> On Sun, Mar 23, 2014 at 08:39:03PM +0100, aperi2007 wrote:
>
>> A suo  tempo , quando mi giunse questa tua notizia, mi informai e
>> emerse che la geos non è thread-safe
>> (lo sapevi ?)
>> Alcune parti in realta' lo sono , ma solo la parte dei messaggi, il
>> resto non lo è.
>> Per cui la parte rilevante, quella della elaborazione non lo è.
>
> Non e' che non lo sia, non e' stata testata in maniera approfondita.
> Se Simone ha condotto questo studio magari ci sa dire.
>

io a suo tempo ho condotto un test abbastanza spinto sull'uso
concorrente spinto della GEOS
CPU quad-core, smacinamento ciclico all'infinito di tutti i
testcases spatialite basati su GEOS, da quattro fino a 16
threads concorrenti, il tutto protratto a sfinimento per un
paio d'ore abbondanti (milioni e milioni di iterazioni).

non ho avuto il piacere di beccare neppure una singola criticita'.
ok, non e' un test rigoroso: ma immagino che permetta quantomeno
di affermare che la GEOS regge discretamente bene, e che i rischi
di qualche collisione tra threads sono assai poco probabili ;-)

ciao Sandro


Maggiori informazioni sulla lista Gfoss