Socket nur für lesen bzw. nur für schreiben öffnen?

[Detlef Bosau]

Ich möchte zur Übersicht Lese- und Schreibzugriff zum Peer trennen.

Ich dachte mir spontan sowas wie

insock = connect(......);
outdock = dup(insock);

shutdown (insock, SHUT_WR);
shutdown (outsock, SHUT_RD);

aber anscheinend mache ich damit das Socket ganz zu.

wie mache ich es richtig?

[Rainer Weikusat]

Detlef Bosau <detlef...@Use-Author-Supplied-Address.invalid>
writes:

> Ich dachte mir spontan sowas wie
>
> insock = connect(......);
> outdock = dup(insock);
>
> shutdown (insock, SHUT_WR);
> shutdown (outsock, SHUT_RD);
>
> aber anscheinend mache ich damit das Socket ganz zu.

Nach dem dup verweisen sowohl insock als auch outsock auf dieselbe
'open file description' im Kernel, dh beide shutdown-Aufrufe beziehen
sich auf dieselbe socket.

[Detlef Bosau]

Das ist mir klar und auch beabsichtigt. (Wer hat eigentlich den neun
Linux-Kern freigegeben? Dieser Schwachsinn mit dem futex regt mich auf.)

Wie läuft denn das bei stdin und stdout? Sind das _immer_ zwei getrennte
File-Strukturen im Kernel? Wie mache ich denn das bei einer seriellen
Schnittstelle?

[Rainer Weikusat]

So das die Dateibeschreiber der Konvention gemaess benutzt werden
obwohl es auch anders ginge:

[rw@sapphire]/var/run/sendmail $echo b>&0
b
[rw@sapphire]/var/run/sendmail $read x <&1
g
[rw@sapphire]/var/run/sendmail $echo $x
g

Fuer sockets kann man das aehnlich machen indem man
poll/select/$younameit benutzt und bei einem file descriptor auf
'Eingabe verfuegbar' und beim anderen auf 'Ausgabe moeglich' wartet.

[Detlef Bosau]

On 01/30/2012 03:30 PM, Rainer Weikusat wrote:
>
> Fuer sockets kann man das aehnlich machen indem man
> poll/select/$younameit benutzt und bei einem file descriptor auf
> 'Eingabe verfuegbar' und beim anderen auf 'Ausgabe moeglich' wartet.

Das tue ich eh schon, ich dachte nur, es sei ästhetischer, dazu zwei FD
zu nehmen. Aber dann müsste das FILE struct, oder wie das Ding im Kernel
heißt, wohl entsprechende flags unterstützen. Und da wird es
problematisch, denn da könnte ich ein Socket vielleicht noch auf read
only setzen oder auf write only (geht das?) aber dann wüsste das Struct
natürlich nicht, welder FD was darf und was nicht.....

[Volker Birk]

Detlef Bosau <detlef...@web.de> wrote:
> Das ist mir klar und auch beabsichtigt. (Wer hat eigentlich den neun
> Linux-Kern freigegeben? Dieser Schwachsinn mit dem futex regt mich auf.)

Ich sehe nicht, dass Futexe "Schwachsinn" wären. Aber Du musst sie ja
nicht direkt benutzen, kannst ja die POSIX-API nehmen.

> Wie läuft denn das bei stdin und stdout? Sind das _immer_ zwei getrennte
> File-Strukturen im Kernel?

Es sind immer die Handles 0 und 1.

> Wie mache ich denn das bei einer seriellen
> Schnittstelle?

Kommt drauf an, was Du damit machen willst. Üblicherweise verwendet man
eine Serielle auch gerne mal als Terminal, und geht deshalb nicht über
stdin und stdout. Oder man hat ein cu dazwischen, wenn's schon sein
muss.

Viele Grüsse,
VB.
--
"If /dev/null is fast in web scale I will use it."

http://www.mongodb-is-web-scale.com/

[Detlef Bosau]

On 01/30/2012 04:03 PM, Volker Birk wrote:
> Detlef Bosau<detlef...@web.de> wrote:
>> Das ist mir klar und auch beabsichtigt. (Wer hat eigentlich den neun
>> Linux-Kern freigegeben? Dieser Schwachsinn mit dem futex regt mich auf.)
>
> Ich sehe nicht, dass Futexe "Schwachsinn" wären. Aber Du musst sie ja
> nicht direkt benutzen, kannst ja die POSIX-API nehmen.
>

Ich benutze sie nicht.

Ich sehe nur alle Nas lang, und heute allein schon zwei oder drei Mal,
daß mein Thunderbird hängt, und wenn ich schaue, worin der hängt, dann
im futex. Und das ist sicher nicht nur in Ubuntu eine Macke, die mich
langsam aber sicher aufregt. Vor allem dann, wenn ich irgendwas arbeite
- und am Ende nichts hilft, als die gnome-Session abzuwürgen.

Mir geht es also nicht um den Sinn und Unsinn von futex, ich sehe nur:
a) Ich erlebe damit immer wieder Probleme in Anwendungen.
b) Aus der man page: CONFORMING TO
This system call is Linux-specific.

Kurz: Es geht offenbar auch ohne.

Überhaupt erreicht Linux mit Gnome langsam eine Stabilität, die Windows
neidisch machen würde.... So stabil, wie das Gerümpel abstürzt....

Die Zeiten, wo man an der uptime eines Linux-Rechners sehen konnte, wann
der letzte Stromausfall war, sind schon ziemlich lange vorbei. Da wird
mir einfach zuviel gespielt und gebastelt. Und ich bin nun mal ein
Mensch, der AUSNEHMEND viel Wert auf Stabilität legt. Kurz: Wenn mir ein
Rechner in (realen) 5 Jahren einmal abstürzt, ist mir das deutlich zuviel.

[Rainer Weikusat]

Detlef Bosau <detlef...@web.de> writes:
> On 01/30/2012 04:03 PM, Volker Birk wrote:
>> Detlef Bosau<detlef...@web.de> wrote:
>>> Das ist mir klar und auch beabsichtigt. (Wer hat eigentlich den neun
>>> Linux-Kern freigegeben? Dieser Schwachsinn mit dem futex regt mich auf.)
>>
>> Ich sehe nicht, dass Futexe "Schwachsinn" wären. Aber Du musst sie ja
>> nicht direkt benutzen, kannst ja die POSIX-API nehmen.
>>
>
> Ich benutze sie nicht.
>
> Ich sehe nur alle Nas lang, und heute allein schon zwei oder drei Mal,
> daß mein Thunderbird hängt, und wenn ich schaue, worin der hängt, dann
> im futex.

Das bedeutet dann das es innerhalb von Thunderbird deadlocks gibt und der
Systemaufruf, der 'warte bis ein lock freigegeben wurde' zur
Verfuegung stellt kann dafuer wirklich nichts :-}.

[...]

> Überhaupt erreicht Linux mit Gnome langsam eine Stabilität, die
> Windows neidisch machen würde.... So stabil, wie das Gerümpel
> abstürzt....
>
> Die Zeiten, wo man an der uptime eines Linux-Rechners sehen konnte,
> wann der letzte Stromausfall war, sind schon ziemlich lange vorbei.

[rw@sapphire]~ $uptime
16:06:51 up 45 days, 19:13, 13 users, load average: 0.04, 0.06, 0.05

Das sind deswegen 'bloss' 45 Tage weil das mein 'workstation'-System
ist und ich das gelegentlich neu starte weil ich andere Hardware mit
dem board verbinden moechte etc. Ich gestehe allerdings freimuetig,
dass ich weiterhin fvwm2 benutzte weil ich den schon immer benutze und
meiner Ansicht nach bekommt man sobald man 'Windows' in nennenswertem
Umfang zu imitieren versucht zwangslaeufig genau das, was man sich
herbeigwuenscht hatte.

http://german.about.com/library/blgzauberl.htm

[Volker Birk]

Detlef Bosau <detlef...@web.de> wrote:
> Ich sehe nur alle Nas lang, und heute allein schon zwei oder drei Mal,
> daß mein Thunderbird hängt, und wenn ich schaue, worin der hängt, dann
> im futex.

Dann hat Thunderbird an der Stelle einen Programmierfehler.

> Mir geht es also nicht um den Sinn und Unsinn von futex, ich sehe nur:
> a) Ich erlebe damit immer wieder Probleme in Anwendungen.
> b) Aus der man page: CONFORMING TO
> This system call is Linux-specific.
> Kurz: Es geht offenbar auch ohne.

Locking ist sinnvoll, setzt man es korrekt ein. Futexe sind da nur eine
Implementierung davon.

> Die Zeiten, wo man an der uptime eines Linux-Rechners sehen konnte, wann
> der letzte Stromausfall war, sind schon ziemlich lange vorbei.

Stimmt. Ich boote hier die Kiste öfters neu, so alle paar Monate. Immer
nach einem Kernel-Update eben.

> Kurz: Wenn mir ein Rechner in (realen) 5 Jahren einmal abstürzt, ist
> mir das deutlich zuviel.

Abstürze können übrigens auch an Mängeln in der Hardware oder in
Treibern liegen.

[Detlef Bosau]

On 01/30/2012 05:29 PM, Volker Birk wrote:
> Detlef Bosau<detlef...@web.de> wrote:
>> Ich sehe nur alle Nas lang, und heute allein schon zwei oder drei Mal,
>> daß mein Thunderbird hängt, und wenn ich schaue, worin der hängt, dann
>> im futex.
>
> Dann hat Thunderbird an der Stelle einen Programmierfehler.

Das mag sein. Die Frage ist, warum das bei Familie Thunderbird keiner
merkt. Zumal ich bei mir keine "Fremdsoftware" habe, abgesehen von einem
Acrobat Reader, den ich nie nutze. Ich nehme nur Software, die ich im
Ubuntu Packetmanager finde, habe auch alle Updates mitgemacht.

Ich habe da, zugegeben, eine gewisse Anwendermentalität. Ich pflege mein
System vernünftig - und erhoffe mir daher eine gewisse Stabilität.

>
> Locking ist sinnvoll, setzt man es korrekt ein. Futexe sind da nur eine
> Implementierung davon.

Das mußt Du mir nicht erklären ;-)

Nur sollte man als Programmierer damit vernünftig umgehen können. Und
man sollte Locking und wechselseitigen Ausschluß auch idiotensicher
anbieten. In Unix haben wir genau dafür das ganz klassische
Monitorkonzept und lassen einen Programmierer nicht mehr ohne weiteres
an Semaphore ran. (Es sei denn, jemand wagt sich ans System V IPC ran,
aber davor haben Programmierer hinreichend respekt.)

Nun gut, es gibt noch andere Kamikaze Calls, ich spiele z.B. derzeit
etwas mit select() rum, auch das geht AFAIK mit unbegrenztem warten, und
auch sowas ist schon megapfui.

>
>> Die Zeiten, wo man an der uptime eines Linux-Rechners sehen konnte, wann
>> der letzte Stromausfall war, sind schon ziemlich lange vorbei.
>
> Stimmt. Ich boote hier die Kiste öfters neu, so alle paar Monate. Immer
> nach einem Kernel-Update eben.
>
>> Kurz: Wenn mir ein Rechner in (realen) 5 Jahren einmal abstürzt, ist
>> mir das deutlich zuviel.
>
> Abstürze können übrigens auch an Mängeln in der Hardware oder in
> Treibern liegen.

Ich weiß.

Aber meine Hardware ist in Ordnung und ich nutze das System sehr defensiv.

Würde ich hier Treiberentwicklung oder Kernelprogrammierung machen, sähe
das definitiv anders aus.

Genauer: Wenn mir jemand erzählt, er mache Kernelprogrammierung, und
behauptet, ihm sei noch nie das System um die Ohren geflogen, glaube ich
dem kein Wort.

[Rainer Weikusat]

Detlef Bosau <detlef...@web.de> writes:
> On 01/30/2012 03:30 PM, Rainer Weikusat wrote:
>>
>> Fuer sockets kann man das aehnlich machen indem man
>> poll/select/$younameit benutzt und bei einem file descriptor auf
>> 'Eingabe verfuegbar' und beim anderen auf 'Ausgabe moeglich' wartet.
>
>
> Das tue ich eh schon, ich dachte nur, es sei ästhetischer, dazu zwei
> FD zu nehmen.

Das habe ich schon verschiedentlich getan und es 'funktioniert' genau
so wie mit stdin und stdout was beides ueblicherweise Dateibeschrieber
sind, die auf denselben 'Vollduplex-Kanal' verweisen: Man benutzt eben
einen nur fuer Eingaben und den anderen nur fuer Ausgaben. Zb kann man
sowas machen (unkompiliertes Beispiel):

struct pollfd pfds[2];
int rc;

pfds->fd = insock;
pfds->event = POLLIN;
pfds[1].fd = outsock;
pfds[1].event = POLLOUT;
while (1) {
rc = poll(pfds, 2, -1);

.
.
.

(outsock sollte man natuerlich nur 'aktivieren' wenn ein Schreibaufruf
vorher EAGAIN zurueckgegeben hatte) und dann bekommt man 'Es gibt
Daten'-Benachrichtigungen fuer insock und 'es koennen Daten
geschrieben werden' fuer outsock obwohl beide sowohl fuer Ein- als
auch Ausgaben benutzt werden koennten und auf dieselbe socket
verweisen.

[Stefan Reuther]

Detlef Bosau wrote:
> Ich sehe nur alle Nas lang, und heute allein schon zwei oder drei Mal,
> daß mein Thunderbird hängt, und wenn ich schaue, worin der hängt, dann
> im futex. Und das ist sicher nicht nur in Ubuntu eine Macke, die mich
> langsam aber sicher aufregt. Vor allem dann, wenn ich irgendwas arbeite
> - und am Ende nichts hilft, als die gnome-Session abzuwürgen.
>
> Mir geht es also nicht um den Sinn und Unsinn von futex, ich sehe nur:
> a) Ich erlebe damit immer wieder Probleme in Anwendungen.
> b) Aus der man page: CONFORMING TO
> This system call is Linux-specific.
>
> Kurz: Es geht offenbar auch ohne.

Es ging jahrelang ohne. Da wurde dann stattdessen eine Variable gepollt
und gelegentlich ge'sleep()'t. Dann hättest du den Prozess also in
nanosleep oder beim sinnlosen Verbraten von CPU-Zeit erwischt. Wenn du
das wieder haben willst, nimm dietlibc :->


Stefan

[Stefan Reuther]

Detlef Bosau wrote:
> insock = connect(......);
> outdock = dup(insock);
>
> shutdown (insock, SHUT_WR);
> shutdown (outsock, SHUT_RD);
>
> aber anscheinend mache ich damit das Socket ganz zu.
>
> wie mache ich es richtig?

Unter FreeBSD sollte das mit 'cap_new' gehen.

So wie ich das sehe, ist das aber ein FreeBSD-Eigengewächs und unter
anderen *ixen nicht verfügbar.


Stefan