Dotaz: Poll epoll descriptoru

[Jardík]

Mám epoll descriptor a v něm přes epoll_ctl zaregistrováno několik descriptorů, jeden z nich je descriptor souboru "/proc/self/mountinfo" (event EPOLLERR).

Pokud provedu epoll_wait() a připojím třeba CD a to přimountuju, soubor /proc/self/mountinfo se změní a dostanu příslušný event (EPOLLERR), což je vpořádku.

Potřebuju ale, aby moje knihovna byla snadno integrovatelná s Qt a GTK, z toho důvodu je součástí veřejného API metoda pro získání toho descriptoru, za účelem možnosti jeho pollování, v Qt např. pomocí QSocketNotifier. Zatím jsem to tedy zkoušel jen v testovacím prográmku, který na epoll descriptor zavolá obyčejný poll(). Problém je, že poll() mi vrátí pouze tehdy, pokud na nějakém descriptoru obsaženém v epollu je událost EPOLLIN, ale nevrátí mi, pokud je na nějakém jen EPOLLERR a nemám tak možnost na událost zareagovat. Otázka zní, jak to "opravit"

Odpovědi

[Jardík]

tady se píše:

Q: Is the epoll file descriptor itself poll/epoll/selectable?

A: Yes. If an epoll file descriptor has events waiting then it will indicate as being readable.

Tak proč tomu tak není?

[Jardík]

Nevíte alespoň o nějakém fóru zaměřeném na vývoj pro linux, kde by věděli?

[chochi]

Ahoj, To asi bude zalezet jaky backend to Qt pouziva (vypadato ze umi backend Unix - select a glib - poll). Podle zdrojaku jadra pri zmeno toho souboru vraci POLLERR | POLLPRI. Select ma zase definici:

#define POLLIN_SET (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP | POLLERR)
#define POLLOUT_SET (POLLWRBAND | POLLWRNORM | POLLOUT | POLLERR)
#define POLLEX_SET (POLLPRI)

Takze bych asi v Qt zkusil zaregitrovat QSocketNotifier s udalasti Write, nebo Exception - to by mohlo pomoct.
Na druhou stranu nechapu co myslis tim zavolat poll na epoll deskriptor - poll by se mel volat na deskriptor souboru ktery chces hlidat.

[Jardík]

Nerozumíme si.

int epollfd = epoll_create();
int mountinfofd = open("/proc/self/mountinfo", O_RDONLY);

struct epoll_event e;
e.events = EPOLLERR; // on tohle sleduje implicitně, ale ničemu nevadí, když to tam napíšu
e.data.fd = mountinfofd;
epoll_ctl(epollfd, EPOLL_CTL_ADD, mountinfofd, &e);

Qt, GTK, nebo ne-gui aplikaci (prostě libovolné používající tu knihovnu) předám epollfd k poll()ování (nebo select()ování, to je jedno) na POLLIN. POLLIN event na epoll descriptoru by měl podle dokumentace nastat vždy, když na některém descriptoru v epollu je nějaký event.

Pokud zavolám přímo epoll_wait(epollfd, ...) na ten epoll descriptor, příslušný event (EPOLLERR) na mountinfofd descriptoru dostanu. Pokud však udělám:

struct pollfd p;
p.fd = epollfd;
p.events = POLLIN;

poll(&p, 1, -1);

Tak poll() nikdy nevrátí, ačkoli by se na epollfd měla objevit (podle toho, jak to chápu) událost POLLIN, když se na mountinfofd objeví libovolná událost (např. onen EPOLLERR). Pokud použiju timeout pro poll, např. poll(&p, 1, 1000); A pak zavolám epoll_wait(epollfd,...), i když poll nevrátil event, ale vím, že jsem médium přimountoval, takže v epollu by měla událost být, tak epoll_wait() taky nevrátí žádnou událost. Jako by se díky tomu poll()u úplně vytratila.

[chochi]

Aha, ja si stejne myslel, ze jsem to spatne pochopil.
Zadny CD tady nemam, ale pokud pouziju loopback mount, tak mi tohle funguje:


#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <poll.h>
#include <sys/epoll.h>

int main() {
	int epollfd = epoll_create(1);
	int mountinfofd = open("/proc/self/mountinfo", O_RDONLY);
	
	struct epoll_event e;
	e.events = EPOLLERR; // on tohle sleduje implicitně, ale ničemu nevadí, když to tam napíšu
	e.data.fd = mountinfofd;
	epoll_ctl(epollfd, EPOLL_CTL_ADD, mountinfofd, &e);

	struct pollfd p;
	p.fd = epollfd;
	p.events = POLLIN;
	
	printf("%i", poll(&p, 1, -1));
	printf(" - %08X\n", p.revents);
}

Mi varti (po primontovani / odmonotvani):


$ ./a.out 
1 - 00000001
$ uname -a
Linux xxx 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux

[Jardík]

Já se omlouvám, já myslel, že to nevracel poll(), ale poll() mi vrací, ale nevrací mi epoll_wait() zavolaný na ten epoll descriptor poté, co mi poll() vrátí.

[Luboš Doležel (Doli)]

To je blbý, ale měl by fungovat trik. Vytvoř si druhý epoll handle, do něj zařaď ten první, a pak poll()uj na tom druhém handlu. Jakmile poll() projde na druhém, tak si událost vyzvedneš na prvním (a takhle to mezi epoll handly funguje, ověřeno).

[Jardík]

A proč tohle funguje narozdíl od předchozího? Vždyť se tam snad děje to samý ... ten epoll pak polluje ten původní epoll a to se ta událost neztratí, proč se vůbec ztratí při použití poll()u, data ze socket descriptoru se mi taky neztratí, když na něj zavolám poll()... jinak kdybych provedl ten trik, nebude to o nějak moc "pomalejší"?

[Jardík]

Mi to přijde padlé na hlavu, přece poll()uju ten descriptor proto, abych věděl, že tam jsou události, né proto, abych je přečetl a ztratily se.

[Luboš Doležel (Doli)]

Zkus to nahlásit jako chybu.

[Jardík]

BUG 24132

[Jardík]

Maxi, toto není řešení mého problému. Je to jenom ošklivý workaround přidávající zbytečnou režii a další zabraný descriptor.

[Max]

Já vím, že to je workaround, ale vypadá to, že to je jediné řešení. Ještě se uvidí, až zareagují na tvůj bug. Ale jak chceš, stáhnu to.
Zdar Max

[chochi]

Tak tohle by fungovat nemelo (koukal jsem na zdrojaky jadra), ale to co psal Doli by pomoct melo.

[Luboš Doležel (Doli)]

Možná jsi to tu už psal, ale zkoušel jsi poll()ovat na POLLERR? Protože něco mi říká, že se do "nadřazených" epoll handlů dostávala kopie události, nikoliv vysloveně EPOLLIN... ale nejsem si už jistý.

[chochi]

Nene, kopie tam nejde, viz fs/eventpoll.c:

		if (epi->ffd.file->f_op->poll(epi->ffd.file, NULL) &
		    epi->event.events)
			return POLLIN | POLLRDNORM;

[lofcek]

Je to zvlastne, ale presne toto iste som riesil. A tiez viem, ze na novsich jadrach sa nevracia EPOLLERR, ale EPOLLIN. A tiez viem, ze ten fejk s tym ze do pollu poslem epollfd by teoreticky mal fungovat a prakticky nefunguje.

Takze zatial najlepsie (aj ked nie idealne riesenie), ktore mam je vytvorit thread ktory cez epoll caka na hranu a hned ako to nastane zapise data do rury. A stav rury sa uz da zistovat cez obycajny poll/select. Je to skarede, ale funkcne.