[Python] gestire processi figli

[Roberto De Ioris]

> 2013/11/30 Manlio Perillo <manlio.perillo a gmail.com>:
>> On 30/11/2013 13:18, Roberto De Ioris wrote:
>>>
>>> [...]
>>>>
>>>> Inoltre, curiosità personale visto che non ho mai fatto test, quale è
>>>> la
>>>>
>>>> differenza tra sigtimedwait e kqueue + apposito filtro o epoll +
>>>> signalfd?
>>>>
>>>>
>>>
>>> che kqueue non usa i segnali, quando un processo muore tutti i poller
>>> in
>>> ascolto vengono svegliati dal kernel.
>>
>>
>> Vero, hai ragione; ricordavo male.
>> kqueue ha sia il filtro EVFILT_PROC che EVFILT_SIGNAL.
>> Io stavo assumendo il solo EVFILT_SIGNAL, che dovrebbe funzionare come
>> signalfd su Linux, credo/spero.
>>
>>
>>> Praticamente non hai nessuno dei
>>> problemi dei segnali unix e (soprattutto) non ti costringe a modificare
>>> la
>>> logica del tuo programma (o a fare trucchi strani, tra cui includo il
>>> mio
>>> poller su waitpid suggerito nella mail di prima).
>>>
>>> Purtroppo su Linux kqueue non c'e' :)
>>>
>>
>> Già, ed un poco alla volta mi sembra stiano aggiungendo interfacce per
>> fare
>> quello che kqueue fa già! A quando procfd? :)
>>
>> Peccato, perchè se Linux avesse implementato kqueue, c'era una remota
>> possibilità di vederlo standardizzato da POSIX entro il prossimo
>> decennio..
>
> E' meglio di epoll()? Perchè?
>

"meglio" e' relativo.

Sono diverse, a cominciare dal fatto che kqueue non si limita a monitorare
file descriptors (ma anche processi, inode, timer...). E' una interfaccia
generica per la programmazione ad eventi.

Con una sola syscall fai tutto, in linux ne viene aggiunta una nuova per
ogni funzionalita' (timerfd, eventfd, signalfd, blahblahfd...) poiche' si
preferisce vedere tutto come un "file descriptor".

Non so quali dei due approcci sia migliore, ma kqueue e' arrivata prima e
piaceva a tutti, portandola su linux avremmo (forse) avuto meno mal di
testa


-- 
Roberto De Ioris
http://unbit.it