Das ist ein C-Programm, kein C++-Programm, daher kompilierst Du es mit gcc und nicht mit g++.
~ % gcc -o test test.c
~ % ./test cdplay: Can't open /dev/cdrom: No medium found
~ %
Hm, danke. Ich habe nur deswegen gefragt, weil für mich nirgends der Slit unmittelbar erkennbar war, sondern es meistens so aussieht, als wäre einfach ein GKrellm gestartet, ohne vom Slit geschluckt worden zu sein.
Kann man im OpenBox-Slit eigentlich auch Dockapps unterbringen?
danke für die schnelle antwort.
habe jetzt selbst noch ein bißchen in dem Manual gelesen und werde dann mal probieren ob ich es hinbekomme ..
gruß,
wantai
Hab mir jetzt angeschaut, wie das im ping aus iputils-ss020927.tar.gz gelöst ist. Ist zwar ein wenig unübersichtlich, aber wenn Du in ping.c nach broadcast_pings suchst, dann ist das nachzuvollziehen.
Dieser Thread wurde von Moderator/in c.rackwitz aus dem Forum ANSI C in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
Eigentlich wertden Signale eher durch Aktionen im Programm und durch kill erzeugt
Die wenigsten Signale weisen auf Fehler hin, die meisten dienen zur Prozesssynchronisation etc...
int fbfd = 0;
fbfd = open("/dev/fb0", O_RDWR);
if (fbfd < 0) {
printf("Error: cannot open framebuffer device.\n");
}
reicht das oder meinst du was anderes?
Hm, ich bin von Berkeley DB nicht sehr begeistert, aber wenn Dich in erster Linie die Performance interessiert, dann schau Dir uU das hier an:
http://www.sleepycat.com/pdfs/wp_perf_0705c1.pdf
http://www.sleepycat.com/customers/pdfs/cs_google_1005D.pdf
hi ponto,
thx again für die antwort...es lag an einem ganz einfachen prob
ich hatte den aufruf des threads nicht mitgepostet, da ich nicht dachte das es daran liegt, aber das tat es ....ich habe statt nur
pthread_create(&m_playThread, NULL, PlayerGB::play, NULL);
zu schreiben so wie es eigentlich richtig wäre
pthread_create(&m_playThread, NULL, PlayerGB::play, NULL);
pthread_join(m_playThread, NULL);
geschrieben
das programm ist also nicht nach dem starten des thread zum aufrufenden thread zurückgegangen sondern ist durch join dort in der schleife hängen geblieben
hier die schleife des play_thread:
pthread_mutex_lock(&m_appState_mutex);
m_appState = PlayerGB::PLAY;
while(m_appState == PlayerGB::PLAY)
{
pthread_cond_wait(¬_playing_cond, &m_appState_mutex);
}
pthread_mutex_unlock(&m_appState_mutex);
hier die funktion stop_funktion
void PlayerGB::stop()
{
pthread_mutex_lock(&m_appState_mutex);
if(m_appState == PlayerGB::PLAY)
{
m_appState = PlayerGB::STOP;
}
pthread_cond_broadcast(¬_playing_cond);
pthread_mutex_unlock(&m_appState_mutex);
return;
}
Das Konzept sieht so aus, dass ich einen Thread zum abspielen der Songs habe ...dieser setzt ein Flag, dass er spielt ...das tut er solange wie er in der schleife ist und auf anweisung wartet...die stop funktion setzt lediglich das Flag auf STOP ...dadurch wird die schleife verlassen, das Playback wird beendet.
grüße
Achso, sorry. Da sollte es nach C99 ein Makro namens __STDC_IEC_559__ geben. Kannst dir ja mal den entsprechenden Teil im C99-Standard(Draft) durchlesen: http://compilers.cs.ucla.edu/~nvk/download/TXT/c9x-draft.txt (ab "Annex F")
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.