C: inotify och SIGIO

[Konservburk]

Jag lyckas inte få SIGIO att fungera med inotify.
Så här står det i man 7 inotify:

Kod: Markera allt

       Since Linux 2.6.25, signal-driven I/O  notification  is  available  for
       inotify  file  descriptors;  see the discussion of F_SETFL (for setting
       the O_ASYNC flag), F_SETOWN, and F_SETSIG in fcntl(2).   The  siginfo_t
       structure (described in sigaction(2)) that is passed to the signal han-
       dler has the following fields set: si_fd is set  to  the  inotify  file
       descriptor number; si_signo is set to the signal number; si_code is set
       to POLL_IN; and POLLIN is set in si_band.

Vet inte riktigt vad jag missat...

Kod: Markera allt

#include <unistd.h>
#include <fcntl.h>
#include <sys/inotify.h>

int main() {
	int fd = inotify_init();
	inotify_add_watch(fd, "testfil", IN_ALL_EVENTS);
	fcntl(fd, F_SETFL, O_ASYNC);
	fcntl(fd, F_SETOWN, getpid());
	for (;;) sleep(1);
}

Tanken är att programmet ska avbrytas med SIGIO om något händer med "testfil", men det vill sig inte alls.
Lustigt nog så fungerar SIGIO bra om jag kör med en vanlig fifo istället:

Kod: Markera allt

#include <unistd.h>
#include <fcntl.h>

int main() {
	int fd = open("testfifo", O_RDWR);
	fcntl(fd, F_SETFL, O_ASYNC);
	fcntl(fd, F_SETOWN, getpid());
	for (;;) sleep(1);
}

Här avbryts programmet som tänkt med SIGIO när jag skriver något till "testfifo".

Varför fungerar det inte med inotify? Några idéer?

[Osprey]

Skillnaden som jag ser vid en hastig anblick är att i det första fallet kör du fcntl mot en "inotify instance" och inte mot "testfile", medan du i det andra kör det direkt mot "testfifo". Vad får du för retur på de anropen..?

[Konservburk]

Skillnaden som jag ser vid en hastig anblick är att i det första fallet kör du fcntl mot en "inotify instance" och inte mot "testfile", medan du i det andra kör det direkt mot "testfifo".

Jag har fått för mig att en "inotify instance" ska fungera som vilken vanlig filedescriptor som helst. Men jag kan ju såklart ha missuppfattat den biten.

Vad får du för retur på de anropen..?

0 och 0 i båda fallen. Jag klippte bort returkollen från exemplet tydlighetens skull.

[Osprey]

Jag har fått för mig att en "inotify instance" ska fungera som vilken vanlig filedescriptor som helst. Men jag kan ju såklart ha missuppfattat den biten.

Ok, det är möjligt att "systemet" hanterar det så att när man kör fcntl mot en inotify-instance så påverkar det implicit alla filer/fifos etc. som ingår i instansen.

Blir det samma resultat även om du anget fullständig path för filnamnet..?

[Konservburk]

Ok, det är möjligt att "systemet" hanterar det så att när man kör fcntl mot en inotify-instance så påverkar det implicit alla filer/fifos etc. som ingår i instansen.

Jag har fattat det som att inotify skickar händelser via en inotify-instance som om det vore en vanlig pipe.

Blir det samma resultat även om du anget fullständig path för filnamnet..?

Ja. Jag här även testat så att själva inotify-biten fungerar som den ska, dvs att det dyker upp events som går att läsa av från filedescriptorn direkt när jag gör något med "testfil".

EDIT: Hitta just detta:

Q: Can I use inotify asynchronously?
Although it is not recommended you can. But use a realtime signal rather than the standard SIGIO one. For switching to asynchronous mode call fcntl() with the F_SETOWN flag similarily to the normal async I/O.

... så jag försöker nu stoppa in fcntl(fd, F_SETSIG, SIGRTMIN); men det hjälper inte alls.

[Osprey]

Nu har jag inte läst på det här i detalj, men är det kanske inte så att den skickar händelsen som en SIGALRM..?
Vad får du för resultat om du skapar en sigcatcher för just den (eller fler) signaler..?

[Edit] Givetvis är det ju en SIGIO precis som du säger...
En catcher för den då alltså....

[Konservburk]

Det som händer om man inte har någon egendefinerad hantering av SIGIO är att programmet avslutas samtidigt som det skrivs ut I/O possible. Det är precis vad som händer i fifo-fallet, men inte med inotify, vilket jag tolkar som att det inte kommer någon signal alls.

Jag kan prova att lägga till en egen hanterare, men jag tvivlar på att det skulle göra någon skillnad annat än att införa ytterligare möjliga felkällor.

[Osprey]

Det jag tänker på är bland annat att om förändringen i filen åstadkommer en SIGIO, så behöver den förmodligen/kanske/sannolikt översättas till en SIGALRM för att väcka sleep(), och om vi ser om det kommer en SIGIO så vet vi om första delen av den kedjan funkar eller inte...

Om det inte kommer någon SIGIO så borde det vara inotify_add_watch som på något sätt inte gör vad den borde, försåvitt det inte är något med att den på något sätt inte funkar ihop med F_SETOWN...

[Konservburk]

Det jag tänker på är bland annat att om förändringen i filen åstadkommer en SIGIO, så behöver den förmodligen/kanske/sannolikt översättas till en SIGALRM för att väcka sleep(), och om vi ser om det kommer en SIGIO så vet vi om första delen av den kedjan funkar eller inte...

Det kommer ingen signal alls. Den försvinner någonstans på vägen om den ens skapas alls.

Om det inte kommer någon SIGIO så borde det vara inotify_add_watch som på något sätt inte gör vad den borde, försåvitt det inte är något med att den på något sätt inte funkar ihop med F_SETOWN...

Det verkar onekligen så. Men det å andra sidan dokumenterat att det ska fungera... så jag vet inte riktigt vad jag ska tro.

Jag har hur som helst löst det hela tills vidare med veckans fulhack. En vanlig fork där jag låter den ena processen bevaka inotify och signalera den andra processen när det händer något. Men jag är såklart fortfarande nyfiken på om någon har fått detta att fungera på "rätt" sätt, och isf hur?

[Osprey]

Det här är ju lite svårt också, eftersom den del som skickar signalen inte i egentlig mening finns i ditt program. Var den egentligen ligger vet jag inte säkert, men antingen finns den väl i något medlänkat lib, eller också finns den i den del av kärnan som ingår i hantering och schemaläggning av processer...