[pyar] multiprocessing, FIFOs y mapas

Marcos Dione mdione en grulic.org.ar
Mie Mar 1 19:14:47 ART 2017


    tengo un problemita que no s'e c'omo solucionar. tengo un sistema que
tiene N workers y un masteri, implementados con multiprocessing. no puedo
usar mltithreading porque una de las libs que uso (mapnik) no lo soporta.
el master mete trabajos para hacer en una cola, los workers sacan
trabajos y laburan, todo muy simple. pero no.

    un worker, cuando termina, puede generar entre 0 y 4 trabajos mas.
hay una condicion de corte que hace que en un momento determinado los
workers siempre devuelven 0 trabajos, asi que eso no es problema. la
complicacion viene cuando es mas eficiente hacer uno de estos nuevos
trabajos inmediatamente que hacer uno de los que ya estan en la cola. o
sea, necesito una pila, realmente, pero multiprocessing no tiene.

    estaba pensando en hacer esto:

* una cola de trabajos A de tamanyo N+1 master->workers.
* una cola B de tamanyo 4*N+1 workers->master para los trabajos nuevos.
* el master inicialmente mete un trabajo (esto es parte del problema).
* luego se queda esperando trabajos nuevos por B, los saca y los mete en
una pila, y de la pila saca y los mete en A. ya estoy viendo que esto
parece estudpido, pero como A tiene un tamanyo limitado, no puedo meter
cosas indefinidamente.
* los workers sacan trabajos de A y eventualemnte meten nuevos en B.
* notar que tanto A como B bloquean si estan vacias o llenas, asi que hay
que teenr mucho ojo con esto.

    como ven, parece medio complicado y hasta fragil: me da la impresion
que va a haber momentos en que los workers van a estar esperando al
master que les de trabajos nuevos, pero este a su vez puede estar
esperando a B. me suena a que voy hacia algo tipo select()/poll() pero
para colas.

    se les ocurre algo mas simple?

    ahora, el problema real de fondo: estoy rendereando mapas tipo
slippy. esto significa que el mapa en zoom level (ZL) 0 (cero) es un solo
cuadradito, pero en ZL 1 son 4, en ZL 2 son 16, en ZL N son 4^N. cada
cuadradito en ZL N se convierte en 4 cuadraditos en ZL N+1, y en general
para renderizar esos 4 cuadradaos voy a necesitar (casi) los mismos datos
que para el de ZL N. adem'as, si un cuadrado est'a vac'io (bah, no es mas
que agua) en ZL N, los 4 en ZL N+1 tambien, asi que no tiene sentido
siquiera intentarlo.

    por eso pense en el coso ese: iniciamente pido renderizar (0,0,0) y
el worker deberia poder decirme cuales de los subcuadrados tiene sentido
renderizar. me estoy dando cuenta que estoy recorriendo un arbol
depth-first, pero los workers tienen veto sobre si tiene sentido seguir
bajando o no.

    boh, me quedo medio largo, y ademas medio los estoy usando de rubber
ducks, pero si tienen una opinion al respecto me vendria bien. espero que
no haya quedado muy largo o enquilombado.

-- 
(Not so) Random fortune:
Terrorism isn't a crime against people or property. It's a crime against
our minds, using the death of innocents and destruction of property to
make us fearful.
	    -- Bruce Schneier


Más información sobre la lista de distribución pyar