Herzlichen Dank für die Info,
ich werd mir mal den Vorschlag mittels UPnP ansehen. Das mit dem Webinterface ist leider keine so gute Idee, da das ganze unabhängig vom Router/Modem sein sollte.
lg, michael
I have a hard problem here, which I can not solve and do not find the right answer on the net:
I have created a detached thread with a clean up routing, the problem is that on my Imac and Ubuntu 9.1 (Dual Core). I am not able to correctly cancel the detached thread in the fallowing code:
#include <iostream>
#include <pthread.h>
#include <sched.h>
#include <signal.h>
#include <time.h>
pthread_mutex_t mutex_t;
using namespace std;
static void cleanup(void *arg){
pthread_mutex_lock(&mutex_t);
cout << " doing clean up"<<endl;
pthread_mutex_unlock(&mutex_t);
}
static void *thread(void *aArgument)
{
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,NULL);
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED,NULL);
pthread_cleanup_push(&cleanup,NULL);
int n=0;
while(1){
pthread_testcancel();
sched_yield();
n++;
pthread_mutex_lock(&mutex_t);
cout << " Thread 2: "<< n<<endl; // REMOVE <<ENDL; and it works!! bUT WHY???
pthread_mutex_unlock(&mutex_t);
}
pthread_cleanup_pop(0);
return NULL;
}
int main()
{
pthread_t thread_id;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr,PTHREAD_CREATE_DETACHED);
int error;
if (pthread_mutex_init(&mutex_t,NULL) != 0) return 1;
if (pthread_create(&thread_id, &attr, &(thread) , NULL) != 0) return 1;
pthread_mutex_lock(&mutex_t);
cout << "waiting 1s for thread...\n" <<endl;
pthread_mutex_unlock(&mutex_t);
int n =0;
while(n<1E3){
pthread_testcancel();
sched_yield();
n++;
pthread_mutex_lock(&mutex_t);
cout << " Thread 1: "<< n<<endl;
pthread_mutex_unlock(&mutex_t);
}
pthread_mutex_lock(&mutex_t);
cout << "canceling thread...\n" <<endl;
pthread_mutex_unlock(&mutex_t);
if (pthread_cancel(thread_id) == 0)
{
//This doesn't wait for the thread to exit
pthread_mutex_lock(&mutex_t);
cout << "detaching thread...\n"<<endl;
pthread_mutex_unlock(&mutex_t);
pthread_detach(thread_id);
while (pthread_kill(thread_id,0)==0)
{
sched_yield();
}
pthread_mutex_lock(&mutex_t);
cout << "thread is canceled";
pthread_mutex_unlock(&mutex_t);
}
pthread_mutex_lock(&mutex_t);
cout << "exit"<<endl;
pthread_mutex_unlock(&mutex_t);
return 0;
}
When I replace the Cout with printf() i workes to the end "exit" , but with the cout (even locked) the executable hangs after outputting "detaching thread...
When I remove the <<endl; in the thread (see code) then it works?? But why??
It would be very cool to know from a Pro, what the problem here is?. Why does this not work even when cout is locked by a mutex!?
Thanks a lot for your support!!
Noch eine Anmerkung hierzu: Im JACK Process Callback ist genaugenommen alles tabu, was den Thread auf unbestimmte Zeit blockieren könnte. In dem von dir geposteten Code verstößt du an zwei Stellen gegen diese Regel:
pthread_mutex_lock(&_this->mutex);
_this->playing_offset.erase(iter->first);
Klar, der Code läuft trotzdem irgendwie, aber wenn er auch bei niedriger Latenz wirklich zuverlässig und ohne Aussetzer funktionieren soll, solltest du auf solche Dinge achten und die Laufzeit so deterministisch wie möglich halten. Wenn dein Callback zu lange braucht, wartet die Soundkarte schließlich vergeblich auf neue Daten. Und das betrifft ggf. nicht nur dein eigenes Programm, sondern auch andere, "unschuldige" JACK-Clients die gleichzeitig laufen und durch die Verzögerung nicht mehr rechtzeitig zum Zuge kommen.
DonnerCobra schrieb:
also unter Win klappt es, schade das es sowas nicht unter Unix/OSX gibt.
Das hat nichts mit Win zu tun, das macht der VC++ Compiler, wenn du ihn darum bittest.
Falls das hier im falschen Forum steht, bitte ins richtige verschieben.
Ich versuche mich die letzte Zeit in die Client/Server-Programmierung (in C ohne PlusPlus - ohne hier jetzt darüber diskutieren zu wollen) einzuarbeiten und habe damit begonnen, mir einen kleinen Chat-Server, den man clientseitig über den Browser bedienen können sollte, zu programmieren.
D.h. Es gibt einen kleinen Frame, in dem man die Texte später einmal eingeben können sollte und einen größeren, in dem die Texte aller anwesenden ausgegeben werden. Dieser größerer Frame macht mir nun schon Kopfzerbrechen, da dort über längere Zeit ja nur Daten ausgegeben werden und ich dort ja nur mit write() oder send() Texte an den Client sende. Nun die Frage: Wie kann ich überprüfen, ob der Filediskriptor noch gültig ist und daher der Client noch vorhanden ist? Denn write() und send() machen nach dem zweiten mal Senden eines Textes einen Exit des Servers.
Im Moment teste ich das ganze noch über eine Telnet-Sitzung, über die ich die Texte eingeben kann, die dann im Browser ausgegeben werden.
huso schrieb:
Leider weiss ich nicht... wie soll ich anfangen ?? -.- bin neu in der Linux Welt
Hast Du schonmal irgendwas mit C programmiert? Ich habe Dir doch schon beschrieben, wie Du das machen kannst.
Wenn nicht: Lern doch bitte mal die Grundlagen von C.
Die Aufgabe ist wirklich nicht schwer, oben ist schon erläutert, welche Schritte Du machen musst.
Hallo Maddis,
ich wollte auch etwas mit den ACTs spielen. Kannst Du mir das Protokoll zukommen lassen? Ich würde mich freuen. Email: a n d @ n u r f u e r s p a m . d e
ohne Leerzeichen natürlich ;-). Vielen DAnk,
Gruß,
Andre
man errno schrieb:
errno is defined by the ISO C standard to be a modifiable lvalue of type int, and must not be explicitly declared; errno may be a macro. errno is thread-local; setting it in one thread does not affect its value in any other thread.
Das steht zu mindest bei mir in der man-page...
MatheStein schrieb:
Vielen Dank für die Antwort!!
Kann ich die Datei "mice" nur via C (syscall) editieren oder gibts da gewisse Standardtools für das manuelle Editieren von Gerätedatein unter beispielsweise ubuntu?
Wenn du nicht willst, dass die C Bibliothek für die Puffert, dann nimm die Funktionen open , read , write und lseek . Das hat den Vorteil, dass du auch die Funktion ioctl verwenden kannst, die dir spezielle Funktionen zu einem Gerät zur Verfügung stellt, z.B. Festplattenmotor abschalten o. Ä.
Das mit dem Cross-Compilieren macht meist mehr Arbeit, als Nutzen. Aber es geht.
Du könntest MinGW + MSys versuchen. Da kriegst du ne Bash unter Windows. Cygwin geht auch. Dabei musst du allerdings noch ein paar Flags setzen, damit er dir eine normale Windows-DLL erzeugt.
Du sagst, dass das Programm "auch unter Windows" funktioniert. Dann müssen es die Autoren ja auch irgendwie compilieren. Am wenigsten Scherereien hast du, wenn du das gleiche Build-System benutzt, wie die. Weil eine DLL, mit dem einen Compiler erstellt, läuft noch lange nicht mit einem Programm, dass mit einem anderen Compiler erstellt wurde.
Nein, eher nicht. Der Klassiker ist ja, dass das mit einer anderen Shell läuft, mit anderem PATH, mit sonst anderen Umgebungsvariablen oä. und sich dadurch irgendwas anders verhält. Lass Dir dochmal im Cronjob die Ausgabe von env(1) zumailen oder so.
Meine man-page sagt zu bind() folgendes:
int bind(int sockfd, const struct sockaddr *addr,
socklen_t addrlen);
[..]
addrlen specifies the size, in bytes, of the
address structure pointed to by addr
[..]
gruß