2011-11-08 13 views

risposta

11

Non proprio. epoll ha senso solo per i descrittori di file che normalmente presentano un comportamento di blocco su lettura/scrittura, come tubi e prese. I descrittori di file normali restituiranno sempre un risultato o una fine del file più o meno immediatamente, quindi epoll non farebbe nulla di utile per loro.

+2

Cioè, funziona, anche se inutilmente: "La funzione poll() sostiene i file regolari ... file regolari sono sempre il polling TRUE per la lettura e la scrittura." http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html La pagina man di epoll (4) dice: "se usato come interfaccia con trigger a livello, epoll è sicuramente un sondaggio più veloce (2), e può essere utilizzato ovunque sia usato quest'ultimo poiché condivide la stessa semantica. " Pertanto, come dice duskwuff, non farà nulla di utile. – mkj

+1

Che è così stupido e sbagliato. Il kernel potrebbe bloccarsi per molte ragioni, dalla rotazione del disco (se si è addormentati), fino al ritardo della rete da una condivisione/unità montata in rete. Qualsiasi tipo di interazione con il dispositivo potrebbe causare un blocco di I/O. selezionare/epoll/poll/kqueue dovrebbe essere fatto per funzionare con qualsiasi descrittore di file e qualsiasi descrizione di file dovrebbe consentire il blocco. – Rahly

+0

@Rahly Questo non è possibile. Il kernel non sa in anticipo se una scrittura in un file verrà bloccata - diversamente da socket o pipe, i buffer per le scritture del filesystem non sono dedicati a un singolo FD, quindi non c'è modo di garantire che siano disponibili per un processo specifico . – duskwuff

11

penso, che non riuscirà a epoll_ctl con EPERM:

EPERM The target file fd does not support epoll. 

se il file non ha un'interfaccia poll().

Il codice attuale è http://lxr.linux.no/#linux+v3.1/fs/eventpoll.c#L1373

1373 /* The target file descriptor must support poll */ 
1374  error = -EPERM; 
1375  if (!tfile->f_op || !tfile->f_op->poll) 
1376    goto error_tgt_fput; 
1377