> > > But my point is that PEP380 in Python 3.3 is already a very solid basis > for building event-loop kind of web-framework with non-blocking-IO that are > single-threaded... >
It's just a PEP describing how to interact in an eventloop. That being said, python misses just the wsgi hook (read: a unique way to interact with all different implementations) to make it usable. It's not web2py's job to be the next event-looped webserver. > > The current recommendation for production-deployment of web2py is Apache, > which (as I understand it) has it's mod_wsgi spawn a python-thread for each > request. This has all the performance-penalties mentioned in the first > video I posted (relating to the GIL), in addition to the famous 10K barrier > of machine resource and system-thread-limits. > Whaaaaat ? if this is reported somewhere please point it out, we'll remove it ASAP. Apache with mod_wsgi is a resource-hog that right now has far better counterparts. Here too, that being said, if there's an apache instance managing something else in your stack, then it could be useful to run a python webserver in it, but it's the only case. > Saying that Rocket and Cherrypy are the main focus, is irrelevant. > It may stay like that for educational/experimentation use-cases, but it > has no relevance to production-deployments. > Glad we agree that web2py is not meant to be used only in threaded webservers. > > But I think the main thing that bugs me is that whenever I start talking > about asunc and non-blocking-I/O in this group, everybody immediately > assume I am just talking about either front-end web-serving, or back-end > database-connections... I am considering I/O as also being ipc or even > in-proc communications - having web2py able to communicate with other > server-side services, and/or different connection-sessions within itself > for "push" enabled "collaborative" use-cases (whether being based on WS, > SSE, LP. or any other...). I am talking about transforming web2py's > internals to being async/event-loop capable, within a single-threaded > deployment story. > It is frustrating to me that people are not getting this message... This IS > the direction that web-development is moving into around the world, and if > web3py will not keep up with this trend, it may not even see the light of > day before being left in the dust of history... And I would deem that a > very sad day for all of us... Web2py is keen on backwards-compatibility - > web3py is not - so it is an opportunity for restructuring some internals > and joining web3py with the rest of the second-decade of the 21's > century... (if not spear-heading it...) > > But your are missing that you didn't present any large usecase for that (meaning IPC in general, not related to the web client-server patterns). "IPC" is just something you agree on your stack to be the common ground. There's no way you'll find, e.g., Erlang talk to Python through their respective native APIs, neither Python to Node's javascript modules. Given that there are a lot of choices on the "external to both", we're back to the beginning: it's far more productive code your own information-exchange-messager than come up with a silver-bullet implementation that fits all IPC paradigms, and force web2(3)py users to have that particular tech in their stack. -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
