that has the same exact issues on the "IPC" matter. If python had only the "twisted-way" of doing things, your code would be "async-ready" yet ^_^ . ATM I'm not that sure were I looked that up - so please bear with me if this is incorrect - but a little while ago running node on multiple processes sharing resources wasn't possible.
On Tuesday, April 16, 2013 7:06:07 PM UTC+2, Ramos wrote: > > and then there was nodejs > > :( > > > > > 2013/4/16 Niphlod <nip...@gmail.com <javascript:>> > >> >>> 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 web2py+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- --- 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
