Lifetime rules for goroutines
Stephen
goroutine (all requests run in their own goroutine, right)?
Experimenting, it seems that on the dev server you can start a
goroutine, return from the request, and the goroutine continues.
On the live server the second goroutine disappears - deferred funcs
are not run, no error or stack trace.
Also, an appengine.Context, which you need to do anything interesting,
is tied to a Request.
Is this all by design?
Andrew Gerrand
> What are the lifetime rules for goroutines started from a request
> goroutine (all requests run in their own goroutine, right)?
A goroutine that does not return will run for as long as the app instance runs.
> Experimenting, it seems that on the dev server you can start a
> goroutine, return from the request, and the goroutine continues.
>
> On the live server the second goroutine disappears - deferred funcs
> are not run, no error or stack trace.
There is no process in place to halt those goroutines. What you
observed may have been launching a goroutine in one instance and then
hitting a different instance when you went to look for it. Another
possibility is that the instance had restarted.
You can start goroutines that run in the background, but they
generally won't be able to do anything interesting, because all API
calls are tied to a Context, which is tied to a Request.
This is all by design.
Andrew
Stephen
Then that's why it didn't work - the goroutine couldn't talk to the
datastore and log it's result using the Context passsed from the
request handler.
Regarding appengine.Context, are there any rules about how many should
be created? Should I create one at the top of a handler and pass it
around? Does it break if you don't? etc...
David Symonds
> Regarding appengine.Context, are there any rules about how many should
> be created? Should I create one at the top of a handler and pass it
> around? Does it break if you don't? etc...
You can do either way. Every call to NewContext with a particular
http.Request will return the same value.
It's probably a better idea to pass the appengine.Context around,
though, because if you start using transactions you'll need to pass
the transactional Context, which is a different object to what is
returned by NewContext.
Dave.