FWIW, you might follow: https://plus.google.com/114657481176404420131/posts/fk7Do3gULKe
I have put my thoughts out there and asked the question of others in Python web world that follow me what they reckon. As to your two extremes. The VM approach is what CloudFoundry/Stackato are doing. Google App Engine is the modified Python and execution environment. There are other approaches used and I mention some companies in that post. Another which has a leaning more towards traditional hosting services is dotCloud who rely on uWSGI. Graham On 27 August 2011 17:28, Chen Zheng <[email protected]> wrote: > On 27 August 2011 14:32, Graham Dumpleton <[email protected]> wrote: >> On 27 August 2011 15:57, Chen Zheng <[email protected]> wrote: >>> Wow, quite a lot to digest, I'll reconsider the situation, thank you >>> very much for the advices, detailed and patient explanations. > >>> Concurrent request is not limited, you can have as many worker >>> processes as you can to handle the requests, they are controlled and >>> started automatically by app server like apache as requests coming in. >>> >>> What's limited here is the function of spawning new thread or process >>> in your application handler code. >> >> And as I said, not being able to spawn a background thread will stop >> various code from not working. >> >> More so now that you are also saying that it will not be possible to >> spawn a new process. >> >> Was the intention only to try and block the fork call, or were you >> intending to also block even stuff like os.system() and os.popen() >> etc? >> >> Are you trying to do this at kernel level or intending to try and run >> Python in a restricted mode using a customised Python? > > > The latter. Currently it's just in experimental phrase, we're trying > to leverage as much we can. Let users run their code unmodified is > perfect, but it seems impossible unless an isolated vm instance is > provided. > > Hope we'll find the balance, minimize the migration cost of existing apps. > > Jaime > >> Google App Engine does use a customised version of Python and other >> methods to implement similar sorts of restrictions. Google gets away >> with forcing such restrictions and requiring applications to be >> written to suit their platform mostly because of who they are, but is >> your intention to be of that sort of platform, or are you trying to >> provide a system where anyone can run any application they want >> without having to modify it. If the latter, I think you will find this >> sort of restrictions to be a big turn off to users. There are times >> where people will want to use background threads or execute system >> applications to do stuff. Even Python itself when querying stuff via >> the 'platform' module will run external applications like 'uname' to >> get information. Stuff like this will break if you are going to block >> creation of all new processes. >> >> Graham >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" 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/modwsgi?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" 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/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en.
