C: How to run Programs asynchronously via system, execlp etc.?

[wolfgang bauer (D)]

Hi

I want to start a program via the system-function. But I have to end most of the started programs,
because my program is blocked as long as the started program runs.

I tried execlp as well. Same result.





--
Gruß, Greetings

[Rainer Weikusat]

Der Effekt der exec*-Funktionen ist, ein neues Programm im aktuellen
Prozeß auszuführen. Möchte man das neue Programm parallell zum
ursprünglichen laufen haben, dann braucht es dafür seinen eigenen
Prozeß. Dh man muß vor dem exec einen forken.

[wolfgang bauer (D)]

02.05.21 , 20:55 , Rainer Weikusat:

> Der Effekt der exec*-Funktionen ist, ein neues Programm im aktuellen
> Prozeß auszuführen. Möchte man das neue Programm parallell zum
> ursprünglichen laufen haben, dann braucht es dafür seinen eigenen
> Prozeß. Dh man muß vor dem exec einen forken.

Danke für den Hinweis. Das ist Neuland für mich, wo ich mich erstmal einlesen muss.
Ggf. frage ich nochmal nach.

P.S. Ich sah die Gruppenendung "programming" und schaltete unbewusst auf englisch. Das kommt,
wenn man zuviel auf einmal macht ;-)




--
Gruß, Greetings

[Christian Hanné]

Am 02.05.2021 um 20:55 schrieb Rainer Weikusat:

> Der Effekt der exec*-Funktionen ist, ein neues Programm im aktuellen
> Prozeß auszuführen. Möchte man das neue Programm parallell zum
> ursprünglichen laufen haben, dann braucht es dafür seinen eigenen
> Prozeß. Dh man muß vor dem exec einen forken.
>

Wer denkt sich so eine kranke Scheiße aus?

[Bastian Blank]

Jeder der kein Windows erschaffen will.

Bitte gehen Sie weiter, es gibt nichts zu sehen!

Bastian

[Marc SCHAEFER]

"wolfgang bauer (D)" <sch...@gmx.de> wrote:
> I want to start a program via the system-function. But I have to end most of the started programs,
> because my program is blocked as long as the started program runs.

man 3 system

DESCRIPTION
The system() library function uses fork(2) to create a child process
that executes the shell command specified in command using execl(3) as
follows:

execl("/bin/sh", "sh", "-c", command, (char *) 0);

system() returns after the command has been completed.

so, zum Beispiel / for example:

$ cat a.c
#include <stdlib.h>

int main(void) {
system("sleep 30&");
}

$ gcc -Wall a.c
$ ./a.out
$ ps -C sleep
PID TTY TIME CMD
6770 pts/1 00:00:00 sleep

Jetzt vielleicht wäre es besser mit einem Wrapper-script, wenn zum
Beispiel etwas mit stdout/err machen willst.

[Bonita Montero]

>>> Der Effekt der exec*-Funktionen ist, ein neues Programm im aktuellen
>>> Prozeß auszuführen. Möchte man das neue Programm parallell zum
>>> ursprünglichen laufen haben, dann braucht es dafür seinen eigenen
>>> Prozeß. Dh man muß vor dem exec einen forken.
>> Wer denkt sich so eine kranke Scheiße aus?

> Jeder der kein Windows erschaffen will.

Die Kernel-APIs von Windows sind Posix melentweit überlegen, lediglich
ineffizient implementiert. Wenn ich sowas wie Signale und Forking schon
seh, da krieg ich die Krätze. Das ist doch ein API-Sammelsurium, das
Leute über Jahrzehnte ergänzt haben ohne, dass das den Eindruck macht,
aus einem Guss zu sein.
Ich hab z.B. mal eine portable Semaphor-Klasse für Windows und Unix
geschrieben und musste feststellen, dass die Union semun mit der man
semctl versorgt (SysV-Semaphoren) nicht in irgendeinem Header defi-
niert ist, sondern man die selbst definierten muss. Wer denkt solch
eine kranke Scheiße aus ?

[Rainer Weikusat]

Falls Du wieder erwarten an einer Erklärung interessiert sein solltest:
Jemand, der zu einem Mehrbenutzersystem, bei dem ein Prozeß mit einem
Terminal assoziert ist und wo "laden und starten eines neuen Programms"
ein Feature der Shell und nicht des Systems war, einfach Unterstützung
für Hintergrundjobs hinzufügen möchte.

Aufgrund des sehr geringen Hauptspeichers funktionierte Multiprogramming
auf diesem System im wesentliche so, daß einer der beide Prozesse für
eine Weile lang im Speicher lief. Danach wurde er unterbrochen und der
Speicherinhalt auf eine Platte geschrieben. Von dieser Platte wurde dann
der vorher gesichert Speicherinhalt des anderen Prozesses geladen, der
danach ebenfalls eine Weile lang im Hauptspeicher lief. Usf.

Hintergrundverarbeitung wurde dann so implementiert, das ein Kopie des
Speicherhinhaltes des grade laufenden Prozessess in einen anderen Teil
des Swapspaces geschrieben wurde, um einen neuen Prozeß zu
erzeugen. Später wurde dieser dann durch den bereits existierenden Code
in den Hauptspeicher verlagert und benutzten den ebenfalls bereits
existieren Code der Shell, der ein neues Programm lud und startete, um
ein anderes Kommando auszuführen.

Die Grundidee hat aber noch eine Menge anderer Einsatzmöglichkeiten.

[Stefan Reuther]

Am 03.05.2021 um 13:42 schrieb Bonita Montero:
>>>> Der Effekt der exec*-Funktionen ist, ein neues Programm im aktuellen
>>>> Prozeß auszuführen. Möchte man das neue Programm parallell zum
>>>> ursprünglichen laufen haben, dann braucht es dafür seinen eigenen
>>>> Prozeß. Dh man muß vor dem exec einen forken.
>>> Wer denkt sich so eine kranke Scheiße aus?
>
>> Jeder der kein Windows erschaffen will.
>
> Die Kernel-APIs von Windows sind Posix melentweit überlegen, lediglich
> ineffizient implementiert.

Ah, Mr. Know-it-all mal wieder.

> Wenn ich sowas wie Signale und Forking schon
> seh, da krieg ich die Krätze. Das ist doch ein API-Sammelsurium, das
> Leute über Jahrzehnte ergänzt haben ohne, dass das den Eindruck macht,
> aus einem Guss zu sein.

Dann reden wir mal darüber, wie man unter Windows Threads erzeugt.

_beginthreadex, bittewas?

> Ich hab z.B. mal eine portable Semaphor-Klasse für Windows und Unix
> geschrieben und musste feststellen, dass die Union semun mit der man
> semctl versorgt (SysV-Semaphoren) nicht in irgendeinem Header defi-
> niert ist, sondern man die selbst definierten muss. Wer denkt solch
> eine kranke Scheiße aus ?

Historisch gewachsen.

Die Kernel-APIs von Windows sind halt auch nur solange geil, wie man
sich nicht um Performance schert. Ja toll, Windows hat Semaphore und
Mutex als Kernelobjekt, kann man mit WaitForMultipleObjects drauf
warten! Scheiß Linux, da geht das nicht! Bis man dann mal feststellt,
das Kernelobjekte halt langsam sind, man viel lieber CRITICAL_SECTION
nutzt. Und schwupps ist man da, wo man unter Unix schon lange ist: bei
einem Userspace-Dingsi, was halt leider mit
select^WaitForMultipleObjects inkompatibel ist.

A propos WaitForMultipleObjects. Mehr als 64 Events wäre schon irgendwie
knorke? Mit poll() kein Ding...


Stefan

[Rainer Weikusat]

Stefan Reuther <stefa...@arcor.de> writes:
> Am 03.05.2021 um 13:42 schrieb Bonita Montero:

[...]

>> Ich hab z.B. mal eine portable Semaphor-Klasse für Windows und Unix
>> geschrieben und musste feststellen, dass die Union semun mit der man
>> semctl versorgt (SysV-Semaphoren) nicht in irgendeinem Header defi-
>> niert ist, sondern man die selbst definierten muss. Wer denkt solch
>> eine kranke Scheiße aus ?
>
> Historisch gewachsen.
>
> Die Kernel-APIs von Windows sind halt auch nur solange geil, wie man
> sich nicht um Performance schert. Ja toll, Windows hat Semaphore und
> Mutex als Kernelobjekt, kann man mit WaitForMultipleObjects drauf
> warten! Scheiß Linux, da geht das nicht!

Natürlich geht das (außer WaitForMultipleObjects). Es gibt nicht nur
SysV IPC sondern seit ewigen Zeiten auch die POSIX-Varianten davon
(sem_open/ sem_init und so).

[Bonita Montero]

> Dann reden wir mal darüber, wie man unter Windows Threads erzeugt.

> _beginthreadex, bittewas?

Ist seit mindestens 15 Jahren History. Du kannst einfach CreateThread
bzw. std::thread nehmen. Aber ansonsten seh ich keinen Grund, weswegen
_beginthreadex ein Problem gewesen sein soll. Das war halt nur ein
Wrapper für CreateThread weil die Runtime sonst keinen Thread-spezifi-
schen Cleanup mitbekam. Heute sollte man eh C++-Threads verwenden weil
die Parameter-Übergabe durch variadische Templates um Größenordnungen
komfortabler ist.

> Die Kernel-APIs von Windows sind halt auch nur solange geil, wie man
> sich nicht um Performance schert. Ja toll, Windows hat Semaphore und
> Mutex als Kernelobjekt, kann man mit WaitForMultipleObjects drauf
> warten! Scheiß Linux, da geht das nicht! Bis man dann mal feststellt,
> das Kernelobjekte halt langsam sind, man viel lieber CRITICAL_SECTION
> nutzt. Und schwupps ist man da, wo man unter Unix schon lange ist: bei
> einem Userspace-Dingsi, was halt leider mit
> select^WaitForMultipleObjects inkompatibel ist.

Du kannst dir auch in weniger als ner Stunde einen Hybriden basteln
der das selbe macht wie ne CRITICAL_SECTION, aber für den Fall, dass
man nicht direkt dem kritischen Abschnitt uncontended im Userspace
auf ein Set mehrerer Kernel-Objekte wartet.
Grundätzlich gibt es aber sehr selten Grund, an der Stelle wo man eine
Datenstruktur mit einem kritischen Abschnitt exklusiv lockt parallel
noch auf andere Ereignisse zu warten. Das sind einfach völlig unter-
schiedliche Anwendungsfälle die Du dummerweise für die selben hälst.

> A propos WaitForMultipleObjects. Mehr als 64 Events wäre schon irgendwie
> knorke? Mit poll() kein Ding...

Es gibt I/O Completion Ports.
Für den Rest reicht MAXIMUM_WAIT_OBJECTS dicke aus.

[Bonita Montero]

> Natürlich geht das (außer WaitForMultipleObjects). Es gibt nicht nur

> SysV IPC ...

SysV-Semaphore sind sowieso Scheiße. Erstens sind die Semaphore nur
nach Nummern zu benennen (wird wohl praktisch nie jemand was anderes
als IPC_PRIVATE nutzen), zweitens muss man sich erst das Semaphor mit
semget() holen und es dann mit semctl() initialisieren. Wenn dann nach
dem semget() und vor dem semctl() ein anderer Theead sich auf dieses
Semaphor bezieht und darauf warten will gibt's Probleme.
Aber immerhin kann man bei SysV-Semaphoren auf mehrere Semaphoren
gleichzeitig warten bzw. z.B. atomar eins hochzählen und ein andereres
gleichzeitig runterzählen. Mag vielleicht sehr selten vorkommen, dass
man das benötigt, ist aber dennoch ziemlich interessant. Das ist zumin-
dest bzgl. Semaphoren allein mehr als WaitForMultilpleObjects kann.

[wolfgang bauer (D)]

03.05.21 , 09:36 , Marc SCHAEFER:


system("sleep 30&");
^

Danke ! Genau was ich gesucht habe. :-)





--
Gruß, Greetings

[Rainer Weikusat]

"wolfgang bauer (D)" <sch...@gmx.de> writes:

> 03.05.21 , 09:36 , Marc SCHAEFER:
>
>
> system("sleep 30&");
> ^
>
> Danke ! Genau was ich gesucht habe. :-)

Das führt das Äquivalent von

/bin/sh -c "sleep 30&"

in einem geforkten Prozeß aus. Das ist sehr viel Overhead dafür, bloß
ein anderes Program zu starten und es gibt außerdem keine Möglichkeit,
an seinen exit status zu kommen, weil hier 2x geforkt wird. Dynamisch
Shellbefehle zusammenzubauen ist auch etwas, das man sich am besten gar
nicht erst angewöhnen möchte: Die Shell stellt eine vollständige
Programmiersprache zur Verfügung und früher oder später findet jemand
einen Weg, den Interpreter dafür an einem Steuerprogramm vorbei zu
programmieren.

Sogar die OpenBSD-Leute, denen «Sicherheit» angeblich über alles geht,
bekommen das immer wieder hin.

Simple Beispielprogramm, daß ein anderes Programm started, ohne auf es
zu warten:

---------
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

pid_t start(char **cmdv)
{
pid_t pid;

pid = fork();
switch (pid) {
case -1:
perror("fork");
exit(1);

case 0:
/* child */
execvp(*cmdv, cmdv);

perror("execvp");
_exit(1);
}

return pid;
}

int main(int argc, char **argv)
{
start(argv + 1);
return 0;
}
--------

Erwartet ein auszuführendes Kommando nebst Argumenten als
Kommandozeilenargumente.

[wolfgang bauer (D)]

03.05.21 , 23:05 , Rainer Weikusat:

> "wolfgang bauer (D)" <sch...@gmx.de> writes:
>> 03.05.21 , 09:36 , Marc SCHAEFER:
>>
>>
>> system("sleep 30&");

[ .. ]

> Das führt das Äquivalent von
>
> /bin/sh -c "sleep 30&"
>
> in einem geforkten Prozeß aus. Das ist sehr viel Overhead dafür, bloß

Wie gesagt, das ist Neuland für mich. Ich ziehe deinen Vorschlag unten vor:

> Simple Beispielprogramm, daß ein anderes Programm started, ohne auf es
> zu warten:
>
> ---------
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> pid_t start(char **cmdv)
> {
> pid_t pid;
>
> pid = fork();
> switch (pid) {
> case -1:
> perror("fork");
> exit(1);
>
> case 0:
> /* child */
> execvp(*cmdv, cmdv);
>
> perror("execvp");
> _exit(1);
> }
>
> return pid;
> }
>
> int main(int argc, char **argv)
> {
> start(argv + 1);
> return 0;
> }

Die Frage die noch übrig bleibt: Nachdem du den Aufruf des asynchron zu startenden Programms
in eine extra-Funktion gepackt hast: Läuft dann nur dieses *darin* gestartete Programm nun als eigener Prozess,
oder läuft mein komplettes Programm nochmal zusätzlich als neuer Prozess ? Oder dient deine Methode
nur der besseren, strukturierteren Übersichtlichkeit und es gibt keinen systeminternen Unterschied ob
ich fork im Hauptprozess (main) oder einer Funktion aufrufe ?





--
Gruß, Greetings

[Marc SCHAEFER]

Rainer Weikusat <rwei...@talktalk.net> wrote:
> Simple Beispielprogramm, daß ein anderes Programm started, ohne auf es
> zu warten:

Das genügt nicht, um Zombien zu vermeiden, dazu entweder SIGCHLD SIG_IGN
oder zwei Mal fork(2).

Und: seit 1984, immer "break" bei "case" bitte :)

[Rainer Weikusat]

Marc SCHAEFER <scha...@alphanet.ch> writes:
> Rainer Weikusat <rwei...@talktalk.net> wrote:
>> Simple Beispielprogramm, daß ein anderes Programm started, ohne auf es
>> zu warten:
>
> Das genügt nicht, um Zombien zu vermeiden, dazu entweder SIGCHLD SIG_IGN
> oder zwei Mal fork(2).

Das ist vollkommen richtig so, denn den Exitstatus des Programms gibt es
aus einem Grund und man möchte den nicht generell wegwerfen.

> Und: seit 1984, immer "break" bei "case" bitte :)

Hier gilt (seit 2020) «Ihr mich auch»: Der Sinn von Code ist es, eine
technische Funktion zu erfüllen und nicht um irgendjemandes
Erwartungshaltungsdefizite herumzuwürgen.

[Rainer Weikusat]

"wolfgang bauer (D)" <sch...@gmx.de> writes:
> 03.05.21 , 23:05 , Rainer Weikusat:

[...]

>> pid_t start(char **cmdv)
>> {
>> pid_t pid;
>>
>> pid = fork();
>> switch (pid) {
>> case -1:
>> perror("fork");
>> exit(1);
>>
>> case 0:
>> /* child */
>> execvp(*cmdv, cmdv);
>>
>> perror("execvp");
>> _exit(1);
>> }
>>
>> return pid;
>> }

[...]

> Die Frage die noch übrig bleibt: Nachdem du den Aufruf des asynchron
> zu startenden Programms in eine extra-Funktion gepackt hast: Läuft
> dann nur dieses *darin* gestartete Programm nun als eigener Prozess,
> oder läuft mein komplettes Programm nochmal zusätzlich als neuer
> Prozess ?

fork erzeugt einen neuen Prozeß, der dasselbe Program aussführt, kehrt
also zweimal zurück: Einmal im ursprünglichen Prozeß, wo es die process
id des neuen Prozesses zurücktgibt. Und einmal im neuen. Da ist der
Rückgabewert 0.

Beispiel:

---------
#include <stdio.h>
#include <unistd.h>

int main(void)
{
char buf[1024];
int rc;

fork();
rc = sprintf(buf, "Ich bin %d.\n", getpid());
write(1, buf, rc);

return 0;
}
---------

[Ich bitte darum, auf einen Hinweis, daß hier der Programmierer eine
ausreichende Puffergröße sichergestellt hat, anstatt eine überflüssige
Laufzeitüberprüfung in den Code zu frickeln, zu verzichten.]

> Oder dient deine Methode nur der besseren, strukturierteren
> Übersichtlichkeit und es gibt keinen systeminternen Unterschied ob ich
> fork im Hauptprozess (main) oder einer Funktion aufrufe ?

Als Funktion habe ich das nur geschrieben, weil sich das anbietet: Wenn
man - ähnlich wie bei system gezwungenermaßen - auf detaillierte
Fehlerbehandlung verzichtet, hat man mit fork drei Zeilen Code anstelle
von einer. Das ist ein unerheblicher Mehraufwand und die Trennung dieser
zwei Funktionen hat auch ihre eigenen Einsatzzwecke.

[Rainer Weikusat]

Rainer Weikusat <rwei...@talktalk.net> writes:
> Marc SCHAEFER <scha...@alphanet.ch> writes:

[...]

>> Und: seit 1984, immer "break" bei "case" bitte :)
>
> Hier gilt (seit 2020) «Ihr mich auch»: Der Sinn von Code ist es, eine
> technische Funktion zu erfüllen und nicht um irgendjemandes
> Erwartungshaltungsdefizite herumzuwürgen.

Vielleicht noch als Anfügung sinnvoll: Dank eines von Google
finanzierten Forschungsprojektes ist bekannt, daß die Anzahl von
case-Zweigen, bei denen ein break vergessen worden war, in einem großen,
kollaborativen Softwareprojekt, an dem viele Leute von durchaus
gemischter Qualifikation mitgewirkt haben (Linux) im unteren,
einstelligen Prozentbereich lag.

Die (mutmaßlich seit 197x gebetsmühlenartig wiederholte) Behauptung,
hier gäbe es ein bedeutendes Problem ist also nachweislich falsch.

[Stefan Reuther]

Am 03.05.2021 um 19:37 schrieb Bonita Montero:
>> Dann reden wir mal darüber, wie man unter Windows Threads erzeugt.
>
>> _beginthreadex, bittewas?
>
> Ist seit mindestens 15 Jahren History.

Das weiß Microsoft offenbar noch nicht.

# A thread in an executable that calls the C run-time library (CRT)
# should use the _beginthreadex and _endthreadex functions for thread
# management rather than CreateThread and ExitThread; this requires the
# use of the multithreaded version of the CRT.

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread

>> Die Kernel-APIs von Windows sind halt auch nur solange geil, wie man
>> sich nicht um Performance schert. Ja toll, Windows hat Semaphore und
>> Mutex als Kernelobjekt, kann man mit WaitForMultipleObjects drauf
>> warten! Scheiß Linux, da geht das nicht! Bis man dann mal feststellt,
>> das Kernelobjekte halt langsam sind, man viel lieber CRITICAL_SECTION
>> nutzt. Und schwupps ist man da, wo man unter Unix schon lange ist: bei
>> einem Userspace-Dingsi, was halt leider mit
>> select^WaitForMultipleObjects inkompatibel ist.

[...]

> Grundätzlich gibt es aber sehr selten Grund, an der Stelle wo man eine
> Datenstruktur mit einem kritischen Abschnitt exklusiv lockt parallel
> noch auf andere Ereignisse zu warten. Das sind einfach völlig unter-
> schiedliche Anwendungsfälle die Du dummerweise für die selben hälst.

Dass dir das Vorstellungsvermögen fehlt, hast du schon öfters bewiesen.

Das andere Ereignis ist normalerweise das Abbruchsignal, "musst nicht
mehr auf diesen kritischen Abschnitt warten, Nutzer hat 'Cancel' gedrückt".

Ein weiterer Grund, Kernelelobjekte zu verwenden, ist, dass man die
zwischen Prozessen sharen kann. Dann kann man den Zugriff auf globale
Ressourcen problemlos über ein Kernelobjekt arbitrieren und muss nicht
einen aufwändigen Arbitrierungsserver bauen.

Linux hätte nicht eventfd erfunden, wenn das nicht ab und an sinnvoll wäre.


Stefan

[Bastian Blank]

Rainer Weikusat wrote:
> hat man mit fork drei Zeilen Code anstelle
> von einer. Das ist ein unerheblicher Mehraufwand und die Trennung dieser
> zwei Funktionen hat auch ihre eigenen Einsatzzwecke.

Aber zum Glück muss man das ja nicht getrennt nutzen, sondern es gibt
"posix_spawn":

https://www.systutorials.com/a-posix_spawn-example-in-c-to-create-child-process-on-linux/
https://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html

Bastian

[Rainer Weikusat]

Meiner persönlichen Ansicht nach ist es sehr unwahrscheinlich, daß einem
jemals auffällt, welche vielfältigen Anwendungsmöglichkeiten sich aus
der «fork/ exec»-Zweiteilung ergeben, wenn man sie nicht erst mal als
solche akzeptiert.

«posix_spawn» ist ein semantisch kompliziertes und funktional
reduziertes Interface, das mal zur Unterstützung MMU-loser System
gedacht war:

The posix_spawn() function and its close relation posix_spawnp() have
been introduced to overcome the following perceived difficulties with
fork(): the fork() function is difficult or impossible to implement
without swapping or dynamic address translation.

[...]

It does not attempt to provide the full functionality of fork()/ exec

[Juergen Ilse]

Hallo,

Das geht auf multitasking Systemen eigentlich ueberall so ...
Die "exec" Funktionen *ersetzen* den ktuell laufeenden Prrozess, "fork"
dupliziert den aktuell laufenden Prozess. Der Ablauf zum erzeugen eines
child-Prozesses (*zusaetzlich* zum gerade laufenden Prozess) ist also
"zusaetzlichen Prozess erzugen" (mit fork, die Unterscheifung zwischen
neuem und alten Prozess ist der return-Wert von fork: beim ursprueng-
lichen Prozess die PID des neu erzeugten Prozesses, beim neu erzeugten
Prozess 0). Im neu erzeugten Prozess kann man dann den laufenden Prozess
durch einen anderen ersetzen mit exec. Was soll daran in irgend einer
Weise krank sein?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[wolfgang bauer (D)]

04.05.21 , 16:23 , Rainer Weikusat:

>> Oder dient deine Methode nur der besseren, strukturierteren
>> Übersichtlichkeit und es gibt keinen systeminternen Unterschied ob ich
>> fork im Hauptprozess (main) oder einer Funktion aufrufe ?
>
> Als Funktion habe ich das nur geschrieben, weil sich das anbietet: Wenn
> man - ähnlich wie bei system gezwungenermaßen - auf detaillierte
> Fehlerbehandlung verzichtet, hat man mit fork drei Zeilen Code anstelle
> von einer. Das ist ein unerheblicher Mehraufwand und die Trennung dieser
> zwei Funktionen hat auch ihre eigenen Einsatzzwecke.

Macht Sinn. Danke für deine Hilfe (Dank auch an die anderen) !




--
Gruß, Greetings

[Bonita Montero]

> Das andere Ereignis ist normalerweise das Abbruchsignal, "musst nicht
> mehr auf diesen kritischen Abschnitt warten, Nutzer hat 'Cancel' gedrückt".

Dazu verwendet man keine kritischen Abschnitte. Kritische Abschnitte
werden auschließlich zum Locken von gemeinsam genutzten Datenstrukturen
genutzt. Abbrüche gibt es dabei nicht, es reicht, dass andere Threads
das Mutex / die CS eben nicht für immer halten, dass der jeweilige
Thread rankommt.
Das Locken eines kritischen Threads canceln - so einen Unsinn habe
ich noch nie gesehen, denn die geteilten Datenstrukturen sind immer
nur kurze Zeit gelockt.

> Ein weiterer Grund, Kernelelobjekte zu verwenden, ist, dass man die

> zwischen Prozessen sharen kann. ...

Du kannst auch mit Memory-Mapping Critical Sections sharen.
Und unter Linux CS die auf Futexen beruhen sogar so sicher, dass der
Absturz einer der Anwendungen toleriert werden kann.

[Bonita Montero]

> Das andere Ereignis ist normalerweise das Abbruchsignal, "musst nicht
> mehr auf diesen kritischen Abschnitt warten, Nutzer hat 'Cancel' gedrückt".

Von der inneren Arbeitsweise einer Criticial Section her ist es
normalerweise auch gar nicht möglich, dass das Locken unterbrochen
werden kann. Unter Windows geht das sowieso nicht wg. der zählenden
Implementation der CS, unter Posix darf der Thrad nach einem Signal
während pthread_mutex_lock dann in Folge was anderes machen als das
Mutex nochmal zu locken - falls es das denn wirklich nochmal duch den
entsprechenden Aufruf physischerweise tut, denn bei einer zählenden
Implementation ist das unmöglich.

Junge, Du bist einfach kein Programmier-Praktiker da dir einiges an
Hintergrund-Wissen dafür fehlt.

[Bonita Montero]

> Das weiß Microsoft offenbar noch nicht.
> # A thread in an executable that calls the C run-time library (CRT)
> # should use the _beginthreadex and _endthreadex functions for thread
> # management rather than CreateThread and ExitThread; this requires the
> # use of the multithreaded version of the CRT.

Das ist veraltet bzw. gilt nicht mehr. Die alten CRTs bis einschließlich
Windows XP haben noch den thread local storage mit TlsAlloc / TlsFree
gehandhabt und wenn Du Code für Versionewn der VC++ Runtime schreibst
die noch mit XP kompatibel ist, dann musst Du tatsächlich _beginthread
verwenden, ansonsten braucht man das nicht.

[Bonita Montero]

> Was soll daran in irgend einer Weise krank sein?

Weil eine exec()-Funktion die nicht den laufenden Prozess ersetzt
viel natürlicher und effizienter wäre. Allein das Forken bzw. das
Erstellen von zwei read-only Page Tables ist schon recht aufwendig.

[Bonita Montero]

> Das weiß Microsoft offenbar noch nicht.
> # A thread in an executable that calls the C run-time library (CRT)
> # should use the _beginthreadex and _endthreadex functions for thread
> # management rather than CreateThread and ExitThread; this requires the
> # use of the multithreaded version of the CRT.

Das ist veraltet bzw. gilt nicht mehr. Das war mal aufgrund einer Ein-
schränkung von Windows Vista so, wo die CRT das Beenden eines Threads
durch DllMain nicht mitbekam (daher fuktioniert unter Vista auch kein
C++-thread_local). Dass die Aussage dort schon etwas fehl am Platz ist
ist schon daran zu erkennen, dass es keine unterschiedlichen CRTs mehr
für multi-threaded und single-threaded Code gibt.

[Bonita Montero]

> Was soll daran in irgend einer Weise krank sein?

[Bonita Montero]

> Das andere Ereignis ist normalerweise das Abbruchsignal, "musst nicht
> mehr auf diesen kritischen Abschnitt warten, Nutzer hat 'Cancel' gedrückt".

Dazu fällt mir noch ein: es wird wohl kaum die Situation geben, wo
das Locken einer gemeinsam genutzten Datenstruktur durch den Nutzer
durch ein Cancel unterbrochen wird.
Außerdem: von der inneren Arbeitsweise einer Criticial Section her ist

[Bonita Montero]

> Das andere Ereignis ist normalerweise das Abbruchsignal, "musst nicht
> mehr auf diesen kritischen Abschnitt warten, Nutzer hat 'Cancel' gedrückt".

Dazu verwendet man keine kritischen Abschnitte. Kritische Abschnitte
werden auschließlich zum Locken von gemeinsam genutzten Datenstrukturen
genutzt. Abbrüche gibt es dabei nicht, es reicht, dass andere Threads
das Mutex / die CS eben nicht für immer halten, dass der jeweilige
Thread rankommt.

> Ein weiterer Grund, Kernelelobjekte zu verwenden, ist, dass man die

[Bonita Montero]

> Das andere Ereignis ist normalerweise das Abbruchsignal, "musst nicht
> mehr auf diesen kritischen Abschnitt warten, Nutzer hat 'Cancel' gedrückt".

Dazu verwendet man keine kritischen Abschnitte. Kritische Abschnitte
werden auschließlich zum Locken von gemeinsam genutzten Datenstrukturen
genutzt. Abbrüche gibt es dabei nicht, es reicht, dass andere Threads
das Mutex / die CS eben nicht für immer halten, dass der jeweilige
Thread rankommt.

> Ein weiterer Grund, Kernelelobjekte zu verwenden, ist, dass man die

[Bonita Montero]

Von wegen der Mehrfach-Postings: mein Server hat die Postings nicht
sofort reflektiert, da hab ich die nochmal anderswo abgesetz. Hab die
bisherigen gecancelt, aber das kommt ja nicht nach überall durch.

[Stefan Reuther]

Am 09.05.2021 um 08:34 schrieb Bonita Montero:
>> Das andere Ereignis ist normalerweise das Abbruchsignal, "musst nicht
>> mehr auf diesen kritischen Abschnitt warten, Nutzer hat 'Cancel'
>> gedrückt".
>
> Dazu fällt mir noch ein: es wird wohl kaum die Situation geben, wo
> das Locken einer gemeinsam genutzten Datenstruktur durch den Nutzer
> durch ein Cancel unterbrochen wird.

Wie oft willst du noch betonen, dass dir die Fantasie fehlt?

> Junge, Du bist einfach kein Programmier-Praktiker da dir einiges an
> Hintergrund-Wissen dafür fehlt.

Danke, das aus deinem Mund adelt mich.

Geräte, in denen ich das mache, fahren in mindestens sechsstelliger
Stückzahl auf der Straße rum.

Die Ressource, auf die man mit einem WaitForMutex wartet, ist halt nicht
immer nur der Listenknoten, wo man mal eben was einketten will.

Und Leuten, die solche Dinge NICHT abbrechbar gestalten, haben wir die
Fantastilliarden Programme zu verdanken, die in den "reagiert nicht"
Status gehen, wenn der Druckertreiber klemmt oder ein Netzwerkpaket zur
Unzeit verlorengeht.


Stefan

[Bonita Montero]

> Wie oft willst du noch betonen, dass dir die Fantasie fehlt?

Ja, Phantasie braucht man dazu, denn ein praktisches Beispiel
gibt es nicht.

> Geräte, in denen ich das mache, fahren in mindestens sechsstelliger
> Stückzahl auf der Straße rum.

Da agierst Du mit wenig Sachverstand, wie sich hier zeigt.
Mit der üblichen zählenen Mutex-Implementation ist eine
nterbrechung nämlich unmöglich.

> Die Ressource, auf die man mit einem WaitForMutex wartet, ist halt
> nicht immer nur der Listenknoten, wo man mal eben was einketten will.

Weder Windows noch Posix Mutex-Implementationen sind cancelbar.
Bei Posix ist es zwar möglich, dass das Warten durch ein Signal
unterbrochen wird, aber Posix verpflichtet dich, das Warten wieder
aufzunehmen. Noch Fragen ?
Das snynchronized bei Java oder .NET ist auch nicht cancelbar;
weil es einfach kein Bedarf dafür gibt.

> Und Leuten, die solche Dinge NICHT abbrechbar gestalten, haben wir die
> Fantastilliarden Programme zu verdanken, die in den "reagiert nicht"
> Status gehen, wenn der Druckertreiber klemmt oder ein Netzwerkpaket zur
> Unzeit verlorengeht.

Du bist ein Mega-Dummschwätzer. Mutexe werden nie so lange gehalten,
dass dabei eine nennbare Relation zu der Zeit die ein Nutzer auf eine
Operation wartet entsteht. Nie.

[Bonita Montero]

> Das snynchronized bei Java oder .NET ist auch nicht cancelbar;
> weil es einfach kein Bedarf dafür gibt.

(unter C# heißts dann wohl lock, aber wie gesagt: es ist nicht
cancelbar)

[Bonita Montero]

Hier, so ist ein Mutex bzw. eine Critical Section i.d.R. implemen-
tiert. Windows macht es so (kann dir auch EnterCriticalSection und
LeaveCriticalSection als Disassembly geben wenn Du es nicht begreifst)
und Posix setzt es zwar nicht so voraus, die Semantik der API ist aber
so ausglegt, dass die Implementation so aussehen kann:

#include <atomic>
#include <cassert>
#include "semaphore.h"

using namespace std;

struct Mutex
{
Mutex();
void Enter();
void Leave();
private:
atomic<unsigned> m_counter;
semaphore m_sem;
};

Mutex::Mutex() :
m_counter( 0 )
{
}

void Mutex::Enter()
{
if( m_counter.fetch_add( 1, memory_order_acquire ) != 0 )
m_sem.wait();
}

void Mutex::Leave()
{
unsigned before = m_counter.fetch_sub( 1, memory_order_release );
assert(before >= 1);
if( before > 1 )
m_sem.release();
}

Wenn ein Thread sich erstmal beim Zähler als wartend registriert
hat kann er das nicht mehr rückgängig machen weil er jeden Zeit-
punkt davon ausgehen muss, dass ein anderer Thread ihn aufweckt.
Daher sind Mutexe üblicherweise nicht cancelbar, zumindest sind
die es unter Windows und Posix nicht.
Dann gibt es noch Monitor-Objekte unter .NET und Java, und der
Mutex-Teil (da steckt noch eine implizite "Condition-Variable"
drin und der Zähler enthält zwei Zähler für die die das Mutex
betreten wollen und die die auf die "CV" warten) und die sind
aufgrund ihrer Architektur nie cancelbar.
Es braucht auch niemand cancelbare Mutexe, denn die werden so
kurz gehalten wie möglich damit die Anwendung eben skaliert und
ein Thread nicht andere ausspielt.

[Bonita Montero]

> Bei Posix ist es zwar möglich, dass das Warten durch ein Signal
> unterbrochen wird, aber Posix verpflichtet dich, das Warten wieder

> aufzunehmen. ...

https://linux.die.net/man/3/pthread_mutex_lock
"If a signal is delivered to a thread waiting for a mutex, upon
return from the signal handler the thread shall resume waiting
for the mutex as if it was not interrupted."
Und Signale wären wohl die einzige Möglichkeit, das Locken eines
Posix-Mutex zu unterbrechen. Die API an sich gibt diese Möglichkeit
nicht her. Und Du Hampelmann meinst, das wäre eine Notwndigkeit ?

[Stefan Reuther]

Am 11.05.2021 um 16:58 schrieb Bonita Montero:
>> Geräte, in denen ich das mache, fahren in mindestens sechsstelliger
>> Stückzahl auf der Straße rum.
>
> Da agierst Du mit wenig Sachverstand, wie sich hier zeigt.
> Mit der üblichen zählenen Mutex-Implementation ist eine
> nterbrechung nämlich unmöglich.

Mit kernelbasierten Lösungen wie CreateMutex/WaitForMultipleObjects/
ReleaseMutex oder anderswo als CreateBinarySemaphore/
AsynchronousReceive/ReleaseSemaphore/WaitForActivity ist das völlig
unproblematisch.

Und Auslöser dieses Teilthreads war, das POSIX eben auch nicht immer das
rosarote vom Ei ist, weil es genau sowas nicht hat.

> Du bist ein Mega-Dummschwätzer. Mutexe werden nie so lange gehalten,
> dass dabei eine nennbare Relation zu der Zeit die ein Nutzer auf eine
> Operation wartet entsteht. Nie.

Es ist schön, dass du hier eine All-Aussage triffst, die sich mit einem
einzigen Gegenbeispiel widerlegen lässt.

pthread_mutex_lock(&mtx);
sleep(2000);
// hier könnte natürlich auch was richtiges stehen.
// z.B. ein open() einer Datei, was normalerweise schnell geht,
// außer heute, wo erst die CD angedreht werden muss, oder wo
// der NFS-Server leider nen Schluckauf hat.
pthread_mutex_unlock(&mtx);


Stefan

[Bonita Montero]

> Mit kernelbasierten Lösungen wie CreateMutex/WaitForMultipleObjects/
> ReleaseMutex oder anderswo als CreateBinarySemaphore/
> AsynchronousReceive/ReleaseSemaphore/WaitForActivity ist das völlig
> unproblematisch.

Solche Mutexe nutzt aber keiner weil die zu langsam sind.
Normale Mutexe werden immer nur so kurz gehalten wie möglich und da
kommt es dementsprechend selten zum Contention-Fall, dass das Locken
und Un-Locken komplett im Userland durchläuft.

> Und Auslöser dieses Teilthreads war, das POSIX eben auch nicht immer das
> rosarote vom Ei ist, weil es genau sowas nicht hat.

Die sind völlig ausreichend. Das Canceln des Warten braucht keiner.

> Es ist schön, dass du hier eine All-Aussage triffst, die sich mit einem
> einzigen Gegenbeispiel widerlegen lässt.
> pthread_mutex_lock(&mtx);
> sleep(2000);
> // hier könnte natürlich auch was richtiges stehen.
> // z.B. ein open() einer Datei, was normalerweise schnell geht,
> // außer heute, wo erst die CD angedreht werden muss, oder wo
> // der NFS-Server leider nen Schluckauf hat.
> pthread_mutex_unlock(&mtx);

Es ging in der Diskussion nicht um die Unterbrechbarkeit des Bodys
innerhalb dessen ich das Mutex halte, sondern um die des Lockens
an sich. Hast Du ja selbst oben so benannt; wieso weichst Du also
jetzt vom Thema ab ?

[Christian Hanné]

Am 04.05.2021 um 16:35 schrieb Rainer Weikusat:



> Die (mutmaßlich seit 197x gebetsmühlenartig wiederholte) Behauptung,
> hier gäbe es ein bedeutendes Problem ist also nachweislich falsch.
>

Da zeigt sich mal wieder, dass Du nicht programmieren kannst.

[Rainer Weikusat]

Christian Hanné <the....@gmail.com> writes:
> Am 04.05.2021 um 16:35 schrieb Rainer Weikusat:

,----

| Vielleicht noch als Anfügung sinnvoll: Dank eines von Google
| finanzierten Forschungsprojektes ist bekannt, daß die Anzahl von
| case-Zweigen, bei denen ein break vergessen worden war, in einem großen,
| kollaborativen Softwareprojekt, an dem viele Leute von durchaus
| gemischter Qualifikation mitgewirkt haben (Linux) im unteren,
| einstelligen Prozentbereich lag.

`----

>> Die (mutmaßlich seit 197x gebetsmühlenartig wiederholte) Behauptung,
>> hier gäbe es ein bedeutendes Problem ist also nachweislich falsch.
>>
>
> Da zeigt sich mal wieder, dass Du nicht programmieren kannst.

Obiges ist eine Tatsache: Das wurde als Nebeneffekt eines
Google-Projektes, in Linux alle switch-Statements mit Anmerkungen zu
versehen, die eine (zukünftig) Benutzung von -Wimplicit-fallthrough
ermöglichen sollten.

Diese Tatsache ermöglicht keine Rückschlüsse auf Personen, die über sie
berichten außer im Fall von

- Leuten, deren Verständnis von «Logik» nichtexistent ist

- solchen, die das Verbreiten von Lügenmärchen über ihnen
unbekannte Personen für eine sinnvolle Politik halten

Mutmaßlich gibt es in diesen Gruppen einiges an Überlappung: Es lügt
sich einfach besser, wenn man wirklich nicht versteht, warum man im
Unrecht ist.

Übrigens gehört diese Selbstentblößung nicht hierher.

[Christian Hanné]

Haha, wer lügt hier wohl???

[Stefan Reuther]

Ich frag mich ja schon geraume Zeit, welche Soziologiefakultät hier
Experimente mit den Persona "Christian Hanne" und "Bonita Montero"
treibt. Selbst die soziophobsten Programmierer, die ich IRL kenne,
stellen sich nicht SO idiotisch an.


Stefan

[Marc Haber]

"Bonita Moreno" postet immerhin seit 2003, damals in dasr selig.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Bonita Montero]

> Ich frag mich ja schon geraume Zeit, welche Soziologiefakultät hier
> Experimente mit den Persona "Christian Hanne" und "Bonita Montero"
> treibt. Selbst die soziophobsten Programmierer, die ich IRL kenne,
> stellen sich nicht SO idiotisch an.

Sockenpuppen-Paranoia findet sich eigentlich immer bei Leuten die
selbst mental nicht rund laufen. Du kannst dich in bester Gesell-
schaft wie der von Detlef Bosau wähnen.

[Marc Haber]

Du musst zugeben dass so jemand wie "Christian Hanne" nicht echt sein
KANN, oder?

[Bonita Montero]

> Du musst zugeben dass so jemand wie "Christian Hanne" nicht echt sein
> KANN, oder?

Keine Ahnung und das ist mir auch egal.

[Juergen Ilse]

Hallo,

Marc Haber <mh+usene...@zugschl.us> wrote:

> Stefan Reuther <stefa...@arcor.de> wrote:
>>Ich frag mich ja schon geraume Zeit, welche Soziologiefakultät hier
>>Experimente mit den Persona "Christian Hanne" und "Bonita Montero"
>>treibt. Selbst die soziophobsten Programmierer, die ich IRL kenne,
>>stellen sich nicht SO idiotisch an.
>
> "Bonita Moreno" postet immerhin seit 2003, damals in dasr selig.

Du menst, dieses Experiment ist scchon vor mmehr alss 15 Jahre aus dem
Ruder gelaufen?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Rainer Weikusat]

Juergen Ilse <ne...@usenet-verwaltung.de> writes:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Stefan Reuther <stefa...@arcor.de> wrote:
>>>Ich frag mich ja schon geraume Zeit, welche Soziologiefakultät hier
>>>Experimente mit den Persona "Christian Hanne" und "Bonita Montero"
>>>treibt. Selbst die soziophobsten Programmierer, die ich IRL kenne,
>>>stellen sich nicht SO idiotisch an.
>>
>> "Bonita Moreno" postet immerhin seit 2003, damals in dasr selig.
>
> Du menst, dieses Experiment ist scchon vor mmehr alss 15 Jahre aus dem
> Ruder gelaufen?

Wer sich an Detlef Bosau erinnern kann, bekämpft vermutlich seit einer
langen Zeit extreme Anfälle von Langeweile damit, pseudonym Leute im
Internet zu beleidigen :-).