It isn't enough that the request handler and other library/platform code be thread safe, the application must be as well.
> Because I'm > assuming that in > production the same interpreter may be handling many WSGI threads and > things like class level caches and such require locking for safety. Any threading that they do is "guaranteed" to be invisible to user code; they can't share any user data, such globals, class definitions, and so on. Given the level of promised isolation, I suspect that they don't thread. (They may be able to clone instances that have completed requests faster than they can reload, but that's different.) > In any case, the desire for the dev server is not necessarily multi- > threadedness, its the ability to handle more than 1 request at a time, > which could be handled with multi-processing if that was really > desired. Yes, one could write a forking dev-server so that applications don't need to be thread safe. But, there is the small matter that the dev data store isn't sharable. (I think that it, like the dev memcache, is just a pile of code in the development platform.) And yes, I realize that there are good reasons why one might want an app instance to call another app instance. Still, that's something that they warned wouldn't work with a single dev server instance and suggested using multiple instances if that was an issue. On Apr 1, 1:28 pm, Mark Wolgemuth <[email protected]> wrote: > Surely, the WSGI request handler itself is thread safe, not? I assume > that the deployment environment is running a threaded interpreter. I > would be suprised if App Engine is running an interpreter-per-request > setup. > > The api does not block me from using RLock from the threading > module... is there some magic I here I should know more about? Are > they just giving me dummy locks? Because I'm assuming that in > production the same interpreter may be handling many WSGI threads and > things like class level caches and such require locking for safety. > > In any case, the desire for the dev server is not necessarily multi- > threadedness, its the ability to handle more than 1 request at a time, > which could be handled with multi-processing if that was really > desired. > > The current design prevents you from posting to another url on the > same instance. (You may ask why you would want to do this, when you > could just call an api function, but there are circumstances where you > want to, such as when the production deployment will point to > different services but the dev does not, eg. auth). > > I guess I could fake all this by running multiple dev servers on same > store and putting a little reverse load balancing proxy in front. > > On Apr 1, 1:16 pm, Andy Freeman <[email protected]> wrote: > > > > > > Put this as vote to provide multithreaded dev server. I promise I > > > won't start my own hosting farm. > > > A multi-threaded dev server only makes sense for thread-safe > > applications. > > > Currently the app engine platform doesn't expose anything that can be > > used to make thread-safe applications. Since the production version > > carefully hides any thread-like behavior, this is unlikely to change. > > > On Apr 1, 6:06 am, Mark Wolgemuth <[email protected]> wrote: > > > > The dev server appears (obviously) to be single threaded, as is the > > > django dev server. > > > > The presents a problem if you want to post to your own server > > > location. An example would be posting to the url provided by > > > create_login_url, which in dev answers at the same location as your > > > app. The server gets stuck waiting for the parent request to finish > > > before allowing the urlfetch to execute, times out and fails. > > > > In production these urls would be answered by different servers, so > > > should work. But to develop I have to hack it so I have 2 separate dev > > > instances running. > > > > There are other circumstances (health checks, etc) where you would > > > conceivably want to POST to yourself. Does anyone know if this is > > > allowed in production? I assume so. > > > > Put this as vote to provide multithreaded dev server. I promise I > > > won't start my own hosting farm. > > > > --Mark- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
