<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[exec() fork() oder boost.process]]></title><description><![CDATA[<p>Hallo Gemeinde,</p>
<p>ich habe hier ein kleines Problem. Und zwar habe ich einen Daemon (Linux) geschrieben, nach dieser Anleitung: <a href="http://web.archive.org/web/20060603181849/http://www.linuxprofilm.com/articles/linux-daemon-howto.html" rel="nofollow">http://web.archive.org/web/20060603181849/http://www.linuxprofilm.com/articles/linux-daemon-howto.html</a></p>
<p>Der Daemon fragt in einem Intervall von 10 Sekunden eine Job-Datenbank ab, ob neue Aufträge vorliegen. Wenn es neue Aufträge gibt, müssen diese an ein PHP-Skript weitergeleitet werden. Das es ein PHP-Skirpt ist, darauf habe ich leider keinen Einfluss.</p>
<p>Um die Job-Infos an das PHP-Skript weiter zu leiten, muss ich ja ein PHP-Prozess starten der Aufruf würde so aussehen: /bin/php worker.php --param job-string</p>
<p>Jetzt habe ich quasi die Wahl, das ganze via system() zu machen, oder mit exec() / fork(), oder auch komplexer mit boost.process. Ich habe mir die Beschreibung aller drei Varianten durchgelesen und mit auch Beispiele angeschaut. Nur weiß ich immer noch nicht welche Vorgehensweise für welche Probleme gedacht sind.</p>
<p>Meine Anforderungen wäre:<br />
* Der Exit-Code des PHP-Prozesses muss gelesen werden<br />
* Wenn der PHP-Prozess stirbt (weil ihn jemand im explizit gekillt hat) muss der Daemon das mit bekommen<br />
* Wenn der Daemon stirbt, muss der PHP-Prozess auch dran glauben, der darf nicht im Hintergrund wüten (sprich parent weg, child weg).</p>
<p>Über ein paar Tipps würde ich mich freuen.</p>
<p>Gruß<br />
The Dude</p>
]]></description><link>https://www.c-plusplus.net/forum/topic/304179/exec-fork-oder-boost-process</link><generator>RSS for Node</generator><lastBuildDate>Mon, 10 Aug 2026 00:49:47 GMT</lastBuildDate><atom:link href="https://www.c-plusplus.net/forum/topic/304179.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 31 May 2012 12:06:18 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to exec() fork() oder boost.process on Thu, 31 May 2012 12:06:18 GMT]]></title><description><![CDATA[<p>Hallo Gemeinde,</p>
<p>ich habe hier ein kleines Problem. Und zwar habe ich einen Daemon (Linux) geschrieben, nach dieser Anleitung: <a href="http://web.archive.org/web/20060603181849/http://www.linuxprofilm.com/articles/linux-daemon-howto.html" rel="nofollow">http://web.archive.org/web/20060603181849/http://www.linuxprofilm.com/articles/linux-daemon-howto.html</a></p>
<p>Der Daemon fragt in einem Intervall von 10 Sekunden eine Job-Datenbank ab, ob neue Aufträge vorliegen. Wenn es neue Aufträge gibt, müssen diese an ein PHP-Skript weitergeleitet werden. Das es ein PHP-Skirpt ist, darauf habe ich leider keinen Einfluss.</p>
<p>Um die Job-Infos an das PHP-Skript weiter zu leiten, muss ich ja ein PHP-Prozess starten der Aufruf würde so aussehen: /bin/php worker.php --param job-string</p>
<p>Jetzt habe ich quasi die Wahl, das ganze via system() zu machen, oder mit exec() / fork(), oder auch komplexer mit boost.process. Ich habe mir die Beschreibung aller drei Varianten durchgelesen und mit auch Beispiele angeschaut. Nur weiß ich immer noch nicht welche Vorgehensweise für welche Probleme gedacht sind.</p>
<p>Meine Anforderungen wäre:<br />
* Der Exit-Code des PHP-Prozesses muss gelesen werden<br />
* Wenn der PHP-Prozess stirbt (weil ihn jemand im explizit gekillt hat) muss der Daemon das mit bekommen<br />
* Wenn der Daemon stirbt, muss der PHP-Prozess auch dran glauben, der darf nicht im Hintergrund wüten (sprich parent weg, child weg).</p>
<p>Über ein paar Tipps würde ich mich freuen.</p>
<p>Gruß<br />
The Dude</p>
]]></description><link>https://www.c-plusplus.net/forum/post/2217710</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/2217710</guid><dc:creator><![CDATA[The Dude]]></dc:creator><pubDate>Thu, 31 May 2012 12:06:18 GMT</pubDate></item></channel></rss>