bolug bonner linux user group
news about wissen files archive hilfe suchen  

 

archive :: BoLUG

druckfassung

BoLUG

Re: sleep in C?

To: LUG Bonn <bolug@xxxxxxxxxxx>
Subject: Re: sleep in C?
From: Frank Blatzheim <Frank_Blatzheim@xxxxxx>
Date: Tue, 20 Sep 2005 11:01:55 +0200
Miroslaw Dobrzanski-Neumann schrieb:

> On Mon, Sep 19, 2005 at 05:28:33PM +0200, Frank Blatzheim wrote:
> > man möge mir verzeihen das ich als Nichtkönner etwas in C
> > zusammen gehauen habe.

> >     while (1)
> >     {
> >     read_bytes = read(fd, ev, sizeof(struct input_event) * 64);
> > 
> > Wie bekomme ich das jetzt etwas CPU-freundlicher hin?

> 1. Der Systemaufruf "read" blokiert den Prozess und nicht die CPU. D.h.
>    solange es nichts zu lesen gibt bleibt der Prozess an dieser Stelle hängen.
>    Die CPU Zeit wird anderen Prozessen zugeteilt.

Vielen Dank, das erklärt mir viel. Ich hatte mich schon gewundert,
warum die Endlosschleife so wenig Prozessorlast verursachte.

> 2. Wieso liest du 64 Ereignisse auf einmal und sie dann einzeln auswertest?

"Das ist alles nur geklaut". Ich habe wenig Ahnung was das Programm
wirklich macht. Ich fand es frei verfügbar, liess es laufen und sah
was es tat. Da hinein versuchte ich dann zu bringen, was ich brauche.
Ursprünglich war es eine Demo, die auf alle anfallenden Events
regagiert und diese nur besser lesbar auf den Bildschirm ausgibt.

>    Jede Optimierung verursacht mindestens 2341 Probleme. Ein guter
>    Programmierer schreibt von sich aus einen halbwegs optimierten Code. Das
>    hat aber mit der Optimierung nichts zu tun.

Leider sind die einzigen Programmiersprachen, die ich beherrsche:
Mehrere Basic-Dialekte
ASM auf dem Z80A
Rexx
(in absteigender Fähigkeit)

C finde ich irgendwie krank. Das ist für mich so gut lesbar wie die
umgekehrte polnische Notation (die kann ich nämlich auch nicht
lesen). Man kann sich in alles einarbeiten. Wenn man motiviert ist.
Oder muss. Dies war das erste Mal in Jahren, das ich gezwungen war,
die C-Büchse auf zu machen.

> 5. Sollte die Lösung doch unendlich viel Zeit schlucken liegt das an den
>    aufgerugenen Scripten.

Aus der Praxis beurteilt: Bisher keine Probleme. Das Ganze ist aber
weniger als ein ugly hack. Schon system() ist mir suspect. Ist das
eigentlich ein "vollwertiger" Programmaufruf, aus dem heraus ich
alles starten darf, oder eher eine Art, wie man Shellfunktionen wie
ls mal kurz in C benutzen kann?

[...]
> #include <linux/input.h>
> 
> static char const *PROG = "edevread";
> 
> static inline void *ADVANCE (void *p, ptrdiff_t off)
> {
[...]
Danke für das Code-Beispiel. Um es ansatzweise zu verstehen, muss ich es erst
laufen lassen :-).

Grüße
Frank
-- 
Freie Musik für freie Bürger!
Eine Kampagne des Chaos Computer Clubs (http://www.ccc.de)

 « Vorige im Thread  Dieser Thread  Nächste im Thread » 

 

seitenanfang


 

news about wissen files archive hilfe suchen  
kontakt letzte änderung: 20.09.2005