RejectedSoftware Forums

Sign up

onStart triggers

Is there some method that will trigger as soon as the server starts up?
Currently I have a hack in http/server.d that gets calls a given delegate right before starting up (usage below):

static this() {
    auto settings = new HttpServerSettings;
    settings.port = 23432;
    auto router = new UrlRouter;
    router.get("/", &handleRequest);
    router.get("*", serveStaticFiles("./public/"));
    settings.onStart = () => send(mainTid, SignalVibeReady(true));
    listenHttp(settings, router);
}

Re: onStart triggers

On Sat, 19 Jan 2013 07:04:19 GMT, Joshua Niehus wrote:

Is there some method that will trigger as soon as the server starts up?
Currently I have a hack in http/server.d that gets calls a given delegate right before starting up (usage below):

static this() {
    auto settings = new HttpServerSettings;
    settings.port = 23432;
    auto router = new UrlRouter;
    router.get("/", &handleRequest);
    router.get("*", serveStaticFiles("./public/"));
    settings.onStart = () => send(mainTid, SignalVibeReady(true));
    listenHttp(settings, router);
}

Right now there isn't directly. You could define your own main function though:

int main()
{
	// ..do setup here or in static this()..
	startListening();
	// server is now listening
	return runEventLoop();
}

A more hackish way without modifications is setTimer(dur!"seconds"(0), &onStart); and an alternative approach could be to add a callback for event loop start/end events and use those instead (this probably makes sense to add for other reasons).

But the whole situation with deferred listening is not completely final, yet. After the event loop is started, all listenHttp calls will synchronously start up the server and it would also be nice if they did the same within static this(). The only problem is that the vibedist load balancer is supposed to be able to modify the listening ports to be able to run multiple instances of the same application on the same host - the command line has to be parsed up front though, making it necessary to defer the actual listening.

Maybe there is another way to make both usage scenarios work more seamless together. I'll experiment a little with that when vibedist is on the table again (was held back due to the wait for the new std.process module).

Re: onStart triggers

On Sat, 19 Jan 2013 09:10:10 GMT, Sönke Ludwig wrote:

[..snip..] and an alternative approach could be to add a callback for event loop start/end events and use those instead (this probably makes sense to add for other reasons).

Ahh good idea, ill see if i can get this to work