unter linux sind filedescriptoren zwar gebunden an einen prozess, worauf sie zeigen aber nicht. per unix socket kannst du filedescriptoren anderen prozessen schicken. man 7 unix wird dir unter "Ancillary Messages" helfen.
ingobulla schrieb:
Der Neugierde halber: Wie kann sowas eigentlich passieren? Das ist schließlich nicht irgendeine Library, sondern die Boost und es war als plattform-unabhängig ausgewiesen. Da würde ich nicht erwarten, dass irgendwas aus Versehen im DOS-Format gespeichert ist.
Keine Ahnung. Es ist ja nicht nur so, dass das ganze plattform-unabhängig ist, sondern, dass die configure doch nur unter Unix benutzt wird.
Ich kann mir das nur so vorstellen, dass irgendein Windows-Benutzer bei den Verantwortlichen vor der Veröffentlichung meinte, er müsste die Zeilenumbrüche in der Datei korrigieren. Aber ich weiß es nicht.
Vielleicht könntest du ja einen Bug-Report bei boost machen.
Ich denke, was du brauchst ist "max memory size" oder "virtual memory". Ersteres begrenzt den physischen Speicher, und letzteres, wie der Name schon sagt, den virtuellen Speicher. Welches von beiden du brauchst kommt dann darauf an, was genau du erreichen möchtest.
Nur der Vollständigkeit halber, "max locked memory" bezieht sich auf den Speicher, den ein Programm mittels mlock() vor dem Auslagern auf die Platte schützen kann. Zu "data seg size" kann ich leider nix sagen.
Beachte außerdem, daß das Programm nicht zwangsläufig beendet wird. Solange alle fehlgeschlagenen Speicherallokationen (malloc() gibt NULL zurück, etc.) abgefangen werden, könnte das Programm theoretisch weiterlaufen. Aber wer macht das schon... Und ansonsten wird das Programm auch nicht sauber beendet, sondern halt früher oder später durch einen Segfault o.ä...
mathias_8001 schrieb:
Danke. Das wars. Der erste Parameter ist wohl das Verzeichniss.
es muss nicht das Verzeichnis sein, sondern der ganze Pfad oder das String, wie es aufgerufen wurde, z.b. wenn man ../../program aufruft, dann muss das erste Parameter ../../program sein, bei /bin/ls -alh ist auch das erste Parameter /bin/ls und nicht /bin .
Jetzt versteh ich warum ich gedacht habe, dass poll() auf O_NONBLOCK reagiert!
Folgende Implementierung:
- Netzwerk-Thread der mittels epoll (oder poll) alle Sockets auf Daten überprüft
- fall Daten vorhanden, wird ein Worker-Thread darüber informiert
- Worker-Thread arbeitet die Nachrichten ab, sobald er "die Zeit findet"
-> epoll ist edge-triggered, also alle Nachrichten über die einmal informiert wurde, wird beim nächsten Aufruf ignoriert
-> poll ist level-triggered, also sobald Nachrichten am Socket anliegen, wird darüber informiert (egal ob das schonmal geschehen ist)
Poll returned so lange sofort, bis mein Worker-Thread die Daten abholen konnte. Epoll hingegen tut das nicht. Daher dachte ich, poll reagiert irgendwie auf O_NONBLOCK, was aber nicht der Fall ist
spezialist schrieb:
wie kann das eigentlich sein, dass mein betriebssystem auf dem weg vom einen socket zum anderen socket pakete verliert? oder verstehe ich da etwas nicht.
Oh, ich muss gestehen, das unix domain überlesen zu haben. Da geht natürlich nicht ganz so viel verloren. Es wird aber immer noch keine Zustellung garantiert.
publib.boulder.ibm.com/html/as400/v4r5/ic2924/info/rzab6mst.pdf
gibt zum Beispiel als möglichen Grund an, dass mehr Daten geschrieben als gelesen werden und damit die Puffer volllaufen, so dass nichts mehr reinpasst.
Wenn du aber wirklich Klarheit darüber willst, dann solltest du direkt auf der Mailingliste von den Entwicklern fragen, die Sockets für dein System implementiert haben. Die kennen es ja schließlich wie ihre Westentasche.
Manchmal kommt auch ein verlorengeglaubtes Paket eine halbe Stunde später an, damit muss der Empfänger auch rechnen.
das kann bei streams ja auch passieren.
Ja, aber dort wird einem ja die ganze Logistik abgenommen.
Mir fiel heute auf als ich die Manpages im Internet angesehen habe, das es bei ncurses doch scanw gibt, was scanf entspricht...entweder ich hab das echt total überlesen, oder meine manpages spinnen
da siehst du richtig mit dem PATH.
wenn der folder wo dein script/binary liegt im PATH gesetzt ist kannst du es immer ausführen, bzw deine shell schaut halt in PATH nach.
kannst ja mal "echo PATH" eingeben dann siehst du dein setting.
PATH ändern z.b. mit "export PATH=/pfad1:/pfad2:PATH"
mit ./file bezeichnest du immer das file in der lokalen directory.
nur mal kurz so drüber geschaut:
sollte das callback argument in Pa_OpenDefaultStream() nicht nen pointer sein ?
also &patestCallback
ansonsten mal den gdb bemühen um den segfault zu lokalisieren...
Ivo schrieb:
Ohne GTK usw? Also fuer den Nutzer nicht sichtbar? Klingt irgednwie nach Keylogger, gibt es schon fuer Linux....
Ivo
Genau, allerdings kein Keylogger, sondern ein Hotkey Daemon.
Bin auch Anfänger im Bereich Shell-Scripts und erlaube es mir daher mal meine Frage hier zu posten.
Mein Ziel ist es, das wget mehrere Links gleichzeitig downloadet, die ich mittels sed aus der Datei auslese.
das sieht ca so aus:
#!/bin/bash
i=1
max=3 #Anzahl der Downloads
while [ $i -le $max ]
do
link=`sed -ne "$i p" "$1"`
wget -c -b $link
i=`expr $i + 1`
done
Das erste Argument beim Aufruf ist der Name der Datei mit den Links.
Das Script befindet sich im Ornder /bin und hat als erste Zeile auch "#!/bin/bash" aber es funktioniert nicht wenn ich es aufrufe(kommt wget error "missing URL"), nur wenn ich es über sh aufrufe funzts.
Danke schonmal
EDIT: Ich weiß zwar nicht warum, aber wenn ich das Script umbenne läuft es auch wenn ich es ohne sh Aufrufe o.O
sothis_ schrieb:
nman schrieb:
Doch, mit den entsprechenden Libraries sollte das kein Problem sein.
der einzige unterschied ist, dass ich bei windows ein WSAStartup() ausführen muss. der rest sollte absolut identisch sein. ok, das fehlen von signals unter windows erfordert den aufruf von winapi funktionen wenn man's asynchron haben möchte, aber bibliotheken brauch man für diesen kleinkram nicht
Nein, das stimmt so nicht. Die WinAPI hat vll einige Funktionen, die relativ ähnlich zu den POSIX-(Unix,Linux)-Funktionen sind. Aber auch diese Funktionen unterscheiden sich schon in wichtigen Details voneinander und viele Funktionen gibt es in der WinAPI eben nicht. Sobald man etwas ernsthaftes mit Sockets machen will, ist es nicht damit getan unter Windows vorher nur "WSAStartup" aufzurufen!
/proc bietet ja in der regel nur read-only prozess informationen. sollte also einfach zu simulieren sein
indem du eben entsprechende files anlegst.
für die device files hilft dir vielleicht das hier weiter:
http://www.circlemud.org/~jelson/software/fusd/
damit soll man wohl die IO-syscalls in den userspace umbiegen können.