3. Wo programmiert es sich am komfortabelsten?

Wo programmiert es sich am komfortabelsten?

  • K

    dot schrieb:

    wenn du mich fragst, dann ist fork() schon rein vom Konzept her völlig kaputt...

    10 Parameter vs. 0 Parameter. Ich finde fork() sehr schoen. Aber vielleicht magst du etwas ausfuehrlicher antworten.

    0

  • Allein die Tatsache dass so etwas wie exec() existiert, spricht imo schon ziemlich für sich. Man will eben in der Regel nicht forken, sondern sowas wie CreateProcess(). Aber anstatt einer ordentlichen Lösung für das tatsächliche Problem, gibts eben einen Hack wie exec()...

    0
  • E

    Naja, Hack ... finde es eigentlich ziemlich elegant gelöst.

    0
  • 3

    dot schrieb:

    Man will eben in der Regel nicht forken, sondern sowas wie CreateProcess().

    dude qtf, so obv wrong

    0

  • 314159265358979 schrieb:

    dot schrieb:

    Man will eben in der Regel nicht forken, sondern sowas wie CreateProcess().

    dude qtf, so obv wrong

    Ich sag nicht dass fork() rein prinzipiell schlecht ist. Vor allem in Zeiten da es noch keine Threads gab sicherlich eine praktische und elegante Lösung für viele Dinge. Aber sag mir doch mal bitte, wie oft du bisher fork() aufgerufen hast ohne gleich darauf ein exec() zu machen?

    0
  • B

    dot schrieb:

    Aber sag mir doch mal bitte, wie oft du bisher fork() aufgerufen hast ohne gleich darauf ein exec() zu machen?

    Immer wenn man dazwischen noch irgendwelche Pipes verkabeln will beispielsweise. Das Unix-Konzept basiert halt darauf, elementare Operationen zu identifizieren und zu komponieren; während das Windows-Konzept darin besteht, die häufigsten Fälle bequem zu machen und den Rest irgendwie ... nicht so bequem. Das zieht sich durch jede MS-API, die ich bisher gesehen habe.

    0

  • Jap, ich hab grad etwas drüber nachgedacht und muss zugeben, dass es doch gar nicht sooo verkehrt ist wie ich immer gedacht hab...ich hatte nur einmal das Vergnüngen, fork() und exec() selbst zu implementieren und seit damals fühlte sich beides für mich irgendwie so falsch an, weil fork() und exec() für mich bedeutet: Page Directory kopieren, Handles duplizieren und haufenweise anderen Kram, nur um das alles dann gleich wieder wegzuwerfen...

    0
  • ?

    dot schrieb:

    Jap, ich hab grad etwas drüber nachgedacht und muss zugeben, dass es doch gar nicht sooo verkehrt ist wie ich immer gedacht hab...ich hatte nur einmal das Vergnüngen, fork() und exec() selbst zu implementieren und seit damals fühlte sich beides für mich irgendwie so falsch an, weil fork() und exec() für mich bedeutet: Page Directory kopieren, Handles duplizieren und haufenweise anderen Kram, nur um das alles dann gleich wieder wegzuwerfen...

    fork ist unter Linux nicht teuer, wenn du gleich danach exec aufrust:

    Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.
    0

  • Steffo schrieb:

    fork ist unter Linux nicht teuer, wenn du gleich danach exec aufrust:

    Das ist mir natürlich bewusst. Das Page Directory muss aber dennoch (potentiell unnötigerweise) kopiert werden, auch wenn man nicht sofort die Pages kopiert.

    fork() und CreateProcess() sind imo jedenfalls zwei fundamental unterschiedliche Dinge, die jeweils eigene Syscalls sein sollten. Weder sind fork() und exec() elementare Operationen in einem CreateProcess(), noch umgekehrt. fork() und exec() ist imo lediglich eine Approximation eines CreateProcess(), aber eben nicht völlig äquivalent.

    0
  • ?

    Eben das Duplizieren der Daten fand ich auch schon immer falsch, obwohl es durch Kopieren bei Bedarf immerhin nicht ganz so schlimm ist wie es ohne wäre. Trotzdem frage ich mich, wie man damals auf die Idee kam, es wäre besser den gesamten Prozess zu Klonen statt einen neuen aufzusetzen. (Irgendwo habe ich auch mal etwas darüber gelesen, aber das weiß ich nicht mehr)
    Für mich ist gerade das Anlegen eines neuen Prozesses ein Teil des Kopierens eines Prozesses, also wenn schon, müsste man meiner Meinung nach eher CreateProcess den Vorzug geben.

    0
  • R

    fork ohne execve ist natürlich sinnvoll. Mehrere Prozesse sind deutlich schöner zu benutzen als Threads. Man hat nicht den Sharedstate-Blödsinn, man kann sie killen und sie reißen nicht die ganze Anwendung mit, wenn mal einer ausrastet. Wenn man eh nur ein execve machen will, dann kann man einfach vfork nehmen und der Pagetable wird nicht kopiert.

    0
  • K

    die jeweils eigene Syscalls sein sollten.

    Linux Kernel 2.6: http://bluemaster.iu.hio.no/edu/dark/lin-asm/syscalls.html , syscall 2 und 11.

    Weder sind fork() und exec() elementare Operationen in einem CreateProcess()

    Darum geht es nicht. fork und exec sind elementare Operationen in einer *nix-Umgebung.

    Approximation eines CreateProcess()

    Nur in deinem Kopf. fork und exec wollen nicht CreateProcess von Windows nachahmen.

    0
  • ?

    rüdiger schrieb:

    Wenn man eh nur ein execve machen will, dann kann man einfach vfork nehmen und der Pagetable wird nicht kopiert.

    👍 🙂

    0
  • Z

    Ich bin beeindruckt, zwei Funktionen sind das wichtigste für die Entscheidung, ob die eine Plattform komfortabler als die Andere. 🤡

    0

  • rüdiger schrieb:

    Wenn man eh nur ein execve machen will, dann kann man einfach vfork nehmen und der Pagetable wird nicht kopiert.

    http://tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-vfork.html
    http://www.unixguide.net/unix/programming/1.1.2.shtml

    knivil schrieb:

    die jeweils eigene Syscalls sein sollten.

    Linux Kernel 2.6: http://bluemaster.iu.hio.no/edu/dark/lin-asm/syscalls.html , syscall 2 und 11.

    Du hast da was falsch verstanden, was ich sagen wollte war, dass es sowohl fork() als auch CreateProcess() als eigenen Syscall geben sollte, da keine der beiden Funktionen die jeweils andere ersetzen kann.

    knivil schrieb:

    Weder sind fork() und exec() elementare Operationen in einem CreateProcess()

    Darum geht es nicht. fork und exec sind elementare Operationen in einer *nix-Umgebung.

    Ja, aber fork() gefolgt von exec() ist eben semantisch etwas anderes als CreateProcess(), auch wenn das Ergebnis eine gute Approximation ist. Aber anstatt eben einen entsprechenden Syscall einzuführen, baut man Hacks wie vfork()...

    knivil schrieb:

    Approximation eines CreateProcess()

    Nur in deinem Kopf. fork und exec wollen nicht CreateProcess von Windows nachahmen.

    Das hab ich auch nicht behauptet. Nochmal: Was ich sagen wollte ist, dass fork() gefolgt von exec() imo keine besonders tolle Lösung für das Erzeugen eines neuen Prozesse mit einem anderen Image ist. Ich habe kein Problem mit fork() an sich.

    0
  • R

    dot schrieb:

    rüdiger schrieb:

    Wenn man eh nur ein execve machen will, dann kann man einfach vfork nehmen und der Pagetable wird nicht kopiert.

    http://tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-vfork.html
    http://www.unixguide.net/unix/programming/1.1.2.shtml

    Linux 2.2 ist doch Steinalt (10 Jahre+). Wen interessiert es also noch, dass es auf ungepatchten Linux 2.2 Systemen eine Racecondition geben kann? Wenn man wirklich für so ein altes System etwas programmieren will, dann muss man da eben vorsichtig sein.

    0
Anmelden zum Antworten