Two launch sites

[qrnch-jan]

We have a couple of Rocket application servers which are supported on both unixy and Windows platforms. The Windows versions support execution in two different contexts: Starting a foreground process (useful for development and debugging) and as a proper service (production).

The pseudo code for main() looks something like this:

fn main() {
  let args = parse_cmd_line();

  if args.reg_win_service {
    register_windows_service(args);
    return;
  } else if args.unreg_win_service {
    unregister_windows_service(args);
    return;
  } else if args.run_win_service {
    run_windows_service(args);
    return;
  }

  // Not a window service.  Can be either a unixy platform or Windows foreground. Kick off a tokio runtime and run Rocket.
  // ...
}

Windows services is a subsystem which had its own "main()" entry point. The run_windows_service() will register some callback functions, and then tell Windows to run the service subsystem, and the service's main entry point is called. Within this new "service main" we start a tokio runtime and launch Rocket.

I want our applications to be more conformant with how Rocket applications are meant to be written, and the desire has accelerated since rc2 because it now warns that an abnormal initialization has occurred, which our customers will be asking us about.

However, it's not clear to me how one would accomplish this. Assume the code above, and assume there's another entry point (which the service subsystem calls):

// Called by the service subsystem
fn service_main(args: Vec<OsString>) {
   // This is within the service.  When this point is reached the regular main() is blocked until the service is terminated.
}

Rocket's launch macros make two assumptions:

• There's only one (conceptual) main(). We have two (the regular main() and the service_main()).
• main() is there to start tokio & Rocket (which is true in all cases except when it's a service -- then main() is just there to start the service subsystem, which in turn is meant to initialize tokio and run Rocket).

I actually have never bothered to check if the service_main() runs on a different thread than main(), I always assumed that one shouldn't make that assumption either way. (They make it somewhat difficult to communicate between main() and service_main(), even going so far as telling developers to re-parse the command line arguments in service_main()).

The service subsystem registers a callback for service events. Among them is the "Stop" event. We currently catch this event and translate it to a proper Rocket shutdown (that is to say that it's not just a matter of the actual launch site, it also concerns shutting down).

Is there an obvious way we can be more rocket::launch conformant (to avoid the warning, and lessen the risk for any future problems that may arise from rolling our own launch), but at the same time support two different launch sites for our Rocket instance (one in regular main() and one in our service_main())?

[blackghost1987]

I don't think Rocket limits the number of places the application can be started from, you can have multiple main() functions without any issues, just not in the top module.

I had a similar setup with Windows Services, and had some issues myself. You could check this Feature Request, trying to solve the problem of NOT starting up Rocket in the "application main", but at other places, based on some configuration parameters:
#1881

Maybe the newly added execute() function will help you:
46c441a