Utils/Console: Fix singleton instantiation order (ServerManager / Scheduler)
[senf.git] / Utils / Daemon / Mainpage.dox
index ffde18d..7cb274f 100644 (file)
@@ -1,8 +1,8 @@
 // $Id$
 //
-// Copyright (C) 2007 
-// Fraunhofer Institut fuer offene Kommunikationssysteme (FOKUS)
-// Kompetenzzentrum fuer NETwork research (NET)
+// Copyright (C) 2007
+// Fraunhofer Institute for Open Communication Systems (FOKUS)
+// Competence Center NETwork research (NET), St. Augustin, GERMANY
 //     Stefan Bund <g0dil@berlios.de>
 //
 // This program is free software; you can redistribute it and/or modify
@@ -36,7 +36,7 @@
             // here after setting default parameters
             senf::Daemon::configure();
         }
-
+    
         void init() {
             // Initialize application. Setup all necessary objects. After init()
             // has completed, the startup should not fail
     Since there are times, where separating init() and run() into two separate functions is
     difficult, instead of defining init() and run(), the member main() may be defined. This member
     must call detach() as soon as initialization is completed to detach from the foreground
-    terminal.
+    terminal.    
+    \code
+    class MyDaemon : public senf::Daemon
+    {
+        // 'configure()' like above. Don't implement 'init()' or 'run()' if you implement 'main()'.
+
+        void main() {
+            // Initialize application. Setup all necessary objects. When implementing main(), the
+            // objects will most often live on the stack.
+
+            MyAppObject app;
+
+            if (some_error)
+                // Call Daemon::exit() to terminate execution prematurely
+                exit(1);
+
+            // After initialization is complete, you *must* call 'detach()'.
+
+            detach()
+
+            // Now we can start the application main loop
+
+            app.run();
+        }
+    };
+    \endcode
 
     \see 
         \ref senf::Daemon class \n