hdlorean team mailing list archive

["Adrián Bravo Navarro" <adrianbn@xxxxxxxxx>]

Buenas,

he ido incluyendo threads en algunas partes de la aplicación la ralentizaban
bastante provocando timeouts.
Scheduler ahora solicita los snapshots en un thread y garantiza que no se
solicita más de un snapshot por vez; garantiza concurrencia,vaya.
Watcher trata en un thread la petición del usuario y de cron de realizar un
snapshot, y aunque está preparado para lockear, he comentado los locks,
porque entiendo que no hay sección crítica en estas operaciones. El journal
garantiza que el único acceso concurrente de esta función no cause
problemas. No obstante dejo comentado el código de los locks hasta que
futuras pruebas intensivas determinen la mejor opción.
Backupear items nuevos -tanto al inicio como cuando algo se añade a la
config- se realiza en un thread aparte, evitando (a priori) rasques
innecesarios. Tampoco considero que exista sección crítica en esto, por lo
que dejo comentado de igual manera los locks.

Os recuerdo que el hecho de que, por el momento, no se bloquee la base de
datos para realizar ciertas operaciones supuestamente atómicas puede llevar
a confusión por parte del usuario, más ahora que puede haber varios threads
adicionales insertando en el journal (más vale que el mecanismo de relanzar
las excepciones dblock de david funcione bien). Pensad que en medio de
varias filas de un snapshot de CRON pueden aparecer filas de uno de
USUARIOy el sched planificarlo como le surja xD

Por otro lado he seguido una política de encapsulamiento para las funciones
en threads. Es decir, si antes existía backupNewItems(), ahora esa función
sigue existiendo, pero lo único que hace es crear un thread que invoca a la
función privada __threadedBackupNewItems(). De esta forma no toco los
interfaces de nadie y además queda más limpio el código, porque la llamada
al thread se realiza en un sólo lugar en vez de en cada sitio en que se
llame a backupNewItems().

Os encantará saber (sobretodo a Eze), que ahora la aplicación no rasca -bye
bye dbus timeout- (salvo que habilitemos los patrones y queda por evitar
tirones al cambiar los watches, pero pasa poco a menudo o nunca y estará
esta semana). La parte mala es que han vuelto los famosos:
pysqlite2.dbapi2.ProgrammingError:
SQLite objects created in a thread can only be used in that same thread.The
object was created in thread id 140410637682400 and this is thread id
1112127824 Así que David, tienes tarea de prioridad CRÍTICA.

Posiblemente considerando el journal como sección crítica, no existiría el
problema de concurrencia de sqlite, pero mejor investigar un poco sobre
otras soluciones que sigan permitiendo el acceso de múltiples threads sobre
Journal.

Debido a estas roturas, os recuerdo que Unstable pasará a estar broken (HD
Lorean Broken Edition) y tenéis una versión sobre la que bugfixear en
testing (ojo, testing tiene que funcionar antes y después del bugfix).
También hay en trunk una copia idéntica -de momento- a testing, ambas
funcionales pero sin las últimas features. Por tanto la secuencia queda:

repos varios ---base común/feature request---> Unstable ----feature
freeze----> Testing ------bugfixing------> Trunk.

PD: Vaya turrón.

Saludos
Adri