Why does Google App Engine support a single thread of execution only?

Question

Does anybody have an idea why Google App Engine permits only a single thread of execution for a deployed application?

I personally believe that it has something to d

Answer 1

App Engine uses a request-based execution model - that is, all work is scoped to a request, be it a user-facing one or one initated by another system such as the task queue. While it would be possible to use threads in this environment, most of the use-cases where multi-threading is useful involve long-running processes, which App Engine is not designed for, or offline work, in which case you're better off using the scalable facilities App Engine provides such as the task queue.

Put another way, threads are a specific solution to a general problem. App Engine provides an alternative for most use cases in the form of the Task Queue.

Answer 2

I don't know for sure, but I believe it is probably for security reasons. If they allow multiple threads, they are opening themselves up for a fork() bomb (or threading equivalent). Also, it greatly simplifies resource management - Google only needs to manage a single thread worth of resources per application.

Answer 3

I think this is a misleading question. The App Engine does not allow your application to spawn threads, but the app engine may launch multiple instances of your application or use some sort of threaded or multiprocess request handler. I don't know the specific details but without some sort of parallelism the app engine would be a pretty useless platform.

EDIT

My original answer incorrectly implied that threads are not a useful feature, they have many uses, but the majority of web developers do not manage threads within their applications. Threads are usually managed at lower levels of the application stack.

Answer 4

Google Flexible App Engine can run any executable within a Docker container. You can Dockerize your multi-threaded executable and deploy it on Flexibile App Engine. I've done this and works as expected.

Answer 5

There is a limited alternative to spawning threads in Google App Engine called task queues: http://code.google.com/appengine/docs/python/taskqueue/

EDIT

From http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox:

To allow App Engine to distribute requests for applications across multiple web servers, and to prevent one application from interfering with another, the application runs in a restricted "sandbox" environment. In this environment, the application can execute code, store and query data in the App Engine datastore, use the App Engine mail, URL fetch and users services, and examine the user's web request and prepare the response.

Like other people have pointed out, threads are not supported for securities reason to sandbox applications.

There are many other restrictions within Google App Engine that forces developers to create scalable apps. I believe task queues are just another one of these restrictions because, as opposed to creating a thread on the current machine handling the HTTP request, a task is put into a queue which can then be schedule on and executed by other machines. Tasks queues allow work to shared and distributed amongst machines in a scalable manner.

Answer 6

A new feature that's launched since this question was asked is background threads.

While regular threads are joined when a given request ends (they cannot outlive the requests), background threads do not have this limitation.

Background threads

Code running on manual or basic scaling instances can start a background thread that can outlive the request that spawns it. This allows instances to perform arbitrary periodic or scheduled tasks or to continue working in the background after a request has returned to the user.

Sample code:

from google.appengine.api import background_thread

# sample function to run in a background thread
def change_val(arg):
    global val
    val = arg

if auto:
    # Start the new thread in one command
    background_thread.start_new_background_thread(change_val, ['Cat'])
else:
    # create a new thread and start it
    t = background_thread.BackgroundThread(
        target=change_val, args=['Cat'])
    t.start()