Potientiale for elongerede kønskirtler

Blandt meget andet manglende tankegods i socket-API'et, er en måde at finde ud af om data faktisk er sendt ud på nettet og hvis relevant for protokollen, ACK'et af den anden ende.

Der findes en ioctl til at finde ud af hvor mange bytes der er ankommet, men endnu ikke læst, FIONREAD, som naturligvis ikke er del af POSIX, dertil er den alt for anvendelig.

At ioctl'en hedder FIOmumle, betyder at den arbejder på alle fildescriptorer, således at også pipes, tty'er, USB pipes kan anvende samme generiske facilitet.

Man kunne sågar lade almindelige filer fortælle hvor meget read-ahead der er klar i kernens buffere, hvis man havde de lyster.

Det ligger derfor umiddelbart for, at FIONWRITE bør returnere bytes der er skrevet til en fildescriptor, men endnu ikke leveret til destinationen

Det er også hvad den gør, i FreeBSD.

Og NetBSD.

Linux har ikke FIONWRITE, men lader sockets svare på en ioctl ved navn TIOCOUTQ, der, så vidt jeg kan gennemskue, returnerer samme metrik. Der er lige den arkitektoniske detalje at en TIOmumle ioctl bruges til TTY'er...

VxWorks har også FIONWRITE: For TTY'er, returnerer den antal endnu ikke udskibede tegn, i andre sammenhænge, er det hvor mange bytes der endnu er plads til at skrive.

I ZOS, operativsystemet tidligere kendt som MVS, er FIONWRITE defineret for AF_UNIX sockets, men returnerer hvor mange bytes der endnu kan skrives, før bufferen er fyldt.

I RTOS32, (whatever that is), returnerer FIONWRITE "the number of bytes available to write", altså igen hvor meget plads der er i bufferen, istedet for hvor meget der stadig ligger i den.

Purister som jeg, vil påpege at en funktion der returnerer hvor meget plads der er, burde hedde FIONSPACE.

Det gør den også på FreeBSD.

Og NetBSD.

Linux har ikke FIONSPACE.

Det har RTOS32 naturligvis heller ikke, de bruger jo FIONWRITE.

Ditto for ZOS, ihvertfald for AF_UNIX sockets.

Opensolaris har FIONREAD, men hverken FIONWRITE eller FIONSPACE.

ARGH!

phk

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Markus Hornum-Stenz

Hæ ja, den titel var ingen underdrivelse. Det er vist noget med at når man skriver noget, vil det være rart hvis man kunne vide om det bliver læst?

Men det der med læsbarhed og skrivemotiv er ikke lige din kop te, hva' PHK? Jeg ved intet om socket API'er, men med al respekt:

Efter at have læst sådan en klamamse, sidder jeg tilbage med en fornemmelse af at hensigten med at skrive den - bevidst eller ubevidst - mere er at udstille din ekstraordinære nørdeniveau og få lidt luft for din frustration over dine nørdekollegers middelmådighed, end at kommunikere noget konstruktivt til nogen?

Hmm, måske skal jeg bare lade være med at bilde mig ind at jeg kan læse systemprogrammørblogs....men når du er læsbar, er du en superskribent, så trods alt: Tak for de elongerede kønskirtler

PS: Gad vide hvordan Roald Als ville portrættere dig?

  • 0
  • 0
Carsten Olsen

Var det ikke en ide med nogen møder mellem de forskellige UNIX (alike) lejre?

INGEN i nogen UNIX lejre kan være tjent med tingenes tilstand som du beskriver dem.

Man kunne måske lave en fælles "mail list" hvor alle udviklere kan anmelde forskelligheder i UNIX afarter. Og GURU'erne fra de forskellige UNIX lejre kan skrive hvad de agter at gøre ved "uensartetheden". (Jeg kunne forestille mig nogen kontroversielle svar hvor "elongerede kønskirtler" o.lign. kunne skræmme nogen useriøse folk væk, - og fred med det.)

  • 0
  • 0
Carsten Sonne

Hvis man tager sine interop/portable briller på, så er overstående klassiske eksempler på divergerende snitflader/API, der gør processen sværre og i værste tilfælde stopper den.

Der er nok ikke andre end Austin Group at takke. Generelt har jeg det indtryk at POSIX ikke udvikler sig proaktivt nok, med overstående eksempel til følge.

Måske burde man i Austin Group overveje at strømline beslutningsprocesserne. Helt generelt må man sige, at nogle få uheldige beslutninger sammen med en masse gode, er bedre end et ineffektivt beslutningsorgan.

  • 0
  • 0
Poul-Henning Kamp Blogger

Generelt har jeg det indtryk at POSIX ikke udvikler sig proaktivt nok, med overstående eksempel til følge.

Udvikler POSIX sig da overhovedet ?

Det er mit indtryk at der ingen nytænkning, hvis overhovedet tænkning, er kommet fra den kant siden sidste årtusinde ?

Og ja, det ville sikkert kunne blive stort hvis man kunne sende Linus og nogle strategisk valgte personer til Tristan Da Cune en vinters tid, men det sker ikke, så længe UNIX holdningen til portabilitet er: "De andre skal bare gøre som mig og autocrap-tools tager sig af resten".

Poul-Henning

  • 0
  • 0
Rasmus Toftdahl Olesen

Jeg har fornyligt også stiftet bekendskab med sockets API'erne (i mit tilfælde heldigvis kun Linux sockets og Winsock) og der var virkelig også tendens til lange testikler.

Hvis nu FreeBSD indførte et par nye funktioner der gjorde at man ikke skulle bruge ioctl til at få tingene til at virke så må andre vel også skulle bevæge sig i samme retning for at være "BSD-sockets" compliant?

  • 0
  • 0
Carsten Olsen

Ovenstående søgning skulle skulle give svaret på: "hvorfor er der ikke mere fodslav i UNIX lejren?"

I stedet gav det svaret på et andet spørgsmål. Svaret er: "De sejrede stort fordi UNIX lejren kun så hinanden under slåskampen"

Så mangler vi bare spørgsmålet: "Hvorfor vandt Microsoft 21-0 på OS markedet (1992-96)"

(Jeg ved godt PHK siger at det ikke er noget mål i sig selv at få medlemmer til BSD lejren, det er mere vigtigt med kvaliteten af (de få) medlemmer - men alligevel)

  • 0
  • 0
Jesper S. Møller

Jeg plejer at joke med at 50% af den tid energiske hobbyister bruger på Open Source udvikling bruges på at udvikle stadigt mere sofistikerede skinning APIer til stadig mere obskure windowmanagere som så afvikles af folk der helst vil arbejde i xterm eller tilsvarende. :-)

Hvis bare lidt af dén energi blev flyttet til egentlige problemer som dette ville verden være lidt sjovere og man skulle ikke debugge sære makrosprog for at bygge en Makefil.

Før pthreads var rigtig på plads var der også kloge folk, der kæmpede med at udjævne nogle af de uheldige forskelle imellem sammenlignelige platforme, f.eks. ACE (ja, det er i C++, men det var stadig meget lavniveau og med lavt overhead). Den type projekt kunne man er der åbenbart stadig brug for.

Men det var bare 15 år siden, kører vi i ring eller hvad?

http://www.cs.wustl.edu/~schmidt/ACE.html

  • 0
  • 0
Log ind eller Opret konto for at kommentere