Re: Nebenlaeufigkeit programmieren

Hi Oliver!

Am Fr, 2003-02-14 um 21.16 schrieb Oliver Fromme:
> Marc Santhoff <M.Santhoff(at)t-online.de> wrote:
> > Am Fr, 2003-02-14 um 17.55 schrieb Bernd Walter:
> > > Warum muß die Aufbereitung der Daten asyncron vom Empfang passieren?
> > > Braucht die Aufbereitung so lange?
>
> Das habe ich mich bei der Aufgabenbeschreibung auch geragt.
>
> > Das ist allerdings eine gute Frage. Der Grundgedanke dabei war
> > Modularität und Wiederverwendbarkeit. Für eine schnelle praktikable
> > Lösung hast Du recht, da kann ich auch einen Timer benutzen, der bei
> > Ablauf die Ausführung der weniger aufwendigen Aufgabe anstößt.
>
> Ich verstehe nicht -- wozu ein Timer? Warum kannst Du die
> Daten nicht sofort nach dem Empfang weiterverarbeiten und
> ausgeben? Dauert die Verarbeitung so lang?

Im Gegenteil, die Daten trudeln nur manchmal ein. Deswegen denke ich ein
passender sleep()-Timer wäre was ich will. Schließlich soll das Programm
nicht unnötig rum'poll'en und Systemressourcen verbraten, sondern nur
aktiv werden, wenn's was zu tun gibt.

> Wenn es wirklich notwendig ist, Verarbeitung und Empfang
> weiterer Daten zu parallelisieren, würde ich fork() nehmen.
> Threads halte ich für gefährlich.

Klingt interessant, warum das?

> > Bis ich select() zum springen bekommen habe, hat es zwar etwas gedauert
> > und die comp.programming.os.unix-FAQ (o.ä. aus google) gebraucht, die
> > etwas deutlicher sagt, daß der erste Parameter nicht die Zahl der
> > Deskriptoren
>
> Doch, genau das: der erste Parameter gibt die Anzahl der
> zu selektierenden Deskriptoren an.
>
> > sondern Maximum+1 enthält
>
> Das ist das gleiche. :-)

Nein ...

> select(3, ...) selektiert die ersten drei Deskriptoren,
> d.h. 0 bis 2.

eben, und wenn nur ein fd mit der Nummer 3 abgefragt wird, mu man eben 4
als ersten Parameter für select nehmen, und nicht 1. ;-)
Macht aber nix, ich hab's ja nun verstanden.

Gruß,
Marc

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 15 Feb 2003 - 02:53:26 CET