fork und execvp wrappen
-
Hoi!
Ich arbeite gerade an einer portablen Bibliothek und möchte eine API zur Erzeugung Prozessen miteinbauen.
Dazu würde ich fork + exec* soweit wie möglich wegkapseln wollen, so sieht mein Ansatz aus:
berry::process berry::simple_create_process( std::vector<std::string> const& arguments) { assert(arguments.size() > 0); #ifdef BERRY_LINUX // Fork. berry::process::pid_type result = fork(); if(result == -1) { int error_code = errno; throw berry::system_error("fork() failed", error_code); } else if(result == 0) // We are the child now. { // Create a new array of raw pointers. std::vector<char*> args; args.reserve(arguments.size() + 1); // Copy pointers of the string storages and terminate with a nullptr. for(std::string const& cur : arguments) args.push_back(const_cast<char*>(cur.c_str())); args.push_back(nullptr); // Call execvp to change the process image. execvp(arguments[0].c_str(), &args[0]); // Exit in the case execvp failed. _exit(-1); } else // We are still the parent. { return berry::process(result); } #endif }
Das hat eben 2 Macken:
1. Das Ganze läuft asynchron, dh. es kann sein dass man bereits versucht mit dem neuen Prozess zu arbeiten bevor der überhaupt sein Image gewechselt hat. Kann man da nicht irgendetwas mit wait() machen? Also nur warten bis der neue Prozess läuft und nicht bis er fertig ist.
2. Wenn der Child-Prozess terminiert muss man ja per wait den Status abfragen, sonst schwirrt dieser doch auf ewig als Zombie durchs System. Nur müssen zb Windows-Prozesse das nicht, und das macht es irgendwie recht schwierig da eine einheitliche Schnittstelle zu bauen, hat irgendjemand eine Idee?
Danke und Grüße,
Flo
-
Ethon schrieb:
Das hat eben 2 Macken:
1. Das Ganze läuft asynchron, dh. es kann sein dass man bereits versucht mit dem neuen Prozess zu arbeiten bevor der überhaupt sein Image gewechselt hat. Kann man da nicht irgendetwas mit wait() machen? Also nur warten bis der neue Prozess läuft und nicht bis er fertig ist.
2. Wenn der Child-Prozess terminiert muss man ja per wait den Status abfragen, sonst schwirrt dieser doch auf ewig als Zombie durchs System. Nur müssen zb Windows-Prozesse das nicht, und das macht es irgendwie recht schwierig da eine einheitliche Schnittstelle zu bauen, hat irgendjemand eine Idee?
-
nach dem fork läuft der neue Prozess. Ich glaube nicht, dass man herausbekommt, wann exec "fertig" ist.
-
wait im signalhandler für SIGCHLD aufrufen
-
-
- nach dem fork läuft der neue Prozess. Ich glaube nicht, dass man herausbekommt, wann exec "fertig" ist.
Ich hatte die Idee einfach /proc/[pid]/exe zu checken bis da ein anderer Pfad steht. Nur ist busy waiting immer ekelig.
- wait im signalhandler für SIGCHLD aufrufen
Super, schon eingebaut, danke.
-
Ethon schrieb:
- nach dem fork läuft der neue Prozess. Ich glaube nicht, dass man herausbekommt, wann exec "fertig" ist.
Ich hatte die Idee einfach /proc/[pid]/exe zu checken bis da ein anderer Pfad steht. Nur ist busy waiting immer ekelig.
Was erhoffst du dir denn dadurch?