Funktionsweise select, FD_ISSET, FD_SET

[Para (Gast)]

Hallo zusammen!

Alles Gute für 2018 wünsche ich erstmal!

Könnte mir bitte jemand verständlich erläutern, wie select, FD_SET und 
FD_ISSET funktionieren? Und zwar mehr, was in den Funktionen selbst 
passiert, so dass man diese "nachbilden" kann.. ?!

Danke & Grüße
Para

[Markus F. (mfro)]

Para schrieb:
> so dass man diese "nachbilden" kann..

das macht man am besten gar nicht.

select() war vom ersten Augenblick an eine Fehlkonstruktion (so ähnlich 
wie die Begrenzung von MS-DOS auf 640 KB, weil man "nie" mehr braucht).

select() "lauscht" auf eine (begrenzte) Zahl von File-Deskriptoren und 
kehrt zurück, wenn auf einem von ihnen "was passiert" ist.

Dummerweise ist der höchste mögliche Wert eines solchen File-Deskriptors 
in der Implementierung festgenagelt und reicht praktisch bei allen 
aktuellen Betriebssystemen längst nicht mehr aus. Eine Änderung 
erfordert das Neukompilieren aller Nutzer der Library.

Wenn Du so was "basteln" willst, nimm' dir lieber poll() als Vorbild. 
Das macht praktisch dasselbe. Allerdings ohne Designfehler.

[Para (Gast)]

:-((((

[Markus F. (mfro)]

Para schrieb:
> :-((((

????

[Rufus Τ. F. (rufus)]

Para schrieb:
> Und zwar mehr, was in den Funktionen selbst passiert, so dass man diese
> "nachbilden" kann.. ?!

Du könntest damit anfangen, Dir den Quelltext davon anzuschauen.

[Jim M. (turboj)]

Para schrieb:
> Und zwar mehr, was in den Funktionen selbst
> passiert, so dass man diese "nachbilden" kann.. ?!

Wird bei select() Funktionen eher schwierig, da sie im Kernel 
stattfinden. Viel Spass da den Code zu lesen...

FD_SET und FD_ISSET sind IMHO nur C-Markros, d.h. da muss man halt den 
entsprechenden Header studieren.

Aber auch ich würde lieber poll() einsetzen, wenn der Code nicht auf 20 
Jahre altem Unix arbeiten muss.

[Clemens L. (c_l)]

Jim M. schrieb:
> Wird bei select() Funktionen eher schwierig, da sie im Kernel
> stattfinden. Viel Spass da den Code zu lesen...

Die Implementation von select() ruft poll() auf:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/select.c#n450

Was dann beim Gerätetreiber ankommt, sieht wieder anders aus:
https://lwn.net/Kernel/LDD2/ch05.lwn#t3

Siehe auch:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html
https://stackoverflow.com/questions/970979/what-are-the-differences-between-poll-and-select

[Bernd K. (prof7bit)]

Clemens L. schrieb:
> Jim M. schrieb:
>> Wird bei select() Funktionen eher schwierig, da sie im Kernel
>> stattfinden. Viel Spass da den Code zu lesen...
>
> Die Implementation von select() ruft poll() auf:
> https://git.kernel.org/pub/scm/linux/kernel/git/to...
>
> Was dann beim Gerätetreiber ankommt, sieht wieder anders aus:
> https://lwn.net/Kernel/LDD2/ch05.lwn#t3
>
> Siehe auch:
> http://pubs.opengroup.org/onlinepubs/9699919799/fu...
> https://stackoverflow.com/questions/970979/what-ar...

Und für die Windows-Funktionsweise von select() könnte man einen Blick 
in die Quellen von ReactOS werfen.

[Strubi (Gast)]

Moin,

Um poll()-Mimik nachzubauen muss man nicht zwingend die Kernelsourcen 
durchackern, siehe Doku zum Stichwort 'wait queues'.
Im Prinzip wird nach dem poll() der aktuelle Task vom Scheduler 
schlafengelegt und wieder aufgeweckt, wenn der Treiber Daten hat, 
inzwischen darf ein anderer Task ran.
Dafür musst du halt irgend ein Framework/RTOS bemühen oder nen hack a la 
protothreads..