> > I mean that multiple interpreters are used ONLY to host multiple apps, but > they are not required for this purpose (you can host all of your apps in > the same interpreter, obviously they will share modules and objects). > So, multiple interpreters are only a form of app-isolation
ok. >> hmm... i can understand you design of passing through env dict >> env['uwsgi.core'] and env['.. timeout'] but construction >> request[env['uwsgi.core']].something >> does`t look elegant. I think this is mutch like a threadlocals. > > > yes, very similar in the result. It could be inelegant, but you have not > much choice for storing "local-values". Maybe you can use some > design-pattern to abstract it (check the "request" object in the flask > framework, this is an amazing example of a fake-global object that is > really a local object) > yes i can do abstraction but a double dictionary lookup + string comparison in a poll loop + attribute lookups on top of it worry me. i would better use non-standard non compatible with wsgi solution something like: (core_locals, fd, is_timeout) = yield '' and access my per-request locals as core_locals.my_locals['something'] >> The thing that bothers me - i will use lxml and maybe 1-2 other 3rd >> parity libs (zlib for example) and how it will work out with async >> mode inside signle interpreter.. hmm.. Can i use separate interpreters >> for each async thread ? (i understand that this is memory waste but.. >> this is much more safe) > > > i see no problems if you pay attention to work only on core-specific objects > Agree - you are right. if i pay attention and store everything request-local in a request[env['core']] everything should be fine. >> >> Also a few days ago i saw a real specification at >> http://wsgi.org/wsgi/Specifications/fdevent >> and now a page redirect or gives 404. > > > uWSGI is probably the only one server implementing it, but this is > sub-optimal and i think no-one is currently using it. Its biggest limit is > the inhability to wait for multiple fds. > Don`t understand this: "inhability to wait for multiple fds" isnt mutiple calls to uwsgi.wait_fd_read() will wait for multiple fds? > >> how does uwsgi.send behaves? switches context if would block until all >> data is written? > > that's the idea :) > Hmm.In a very rare situation this can cause a core to be penaltied. Suppose i have 10 write fd connected to remote servers. If one of remote servers is over slow network and accepting data slowly (tcp windows reaches limit) then if i send for example 2Mb of data into such fd.. uWSGI will not give flow to this core back untill all 2Mb is written. This don`t gives me a chance to interrupt writing to slow server and process request without it. > >> should i intercept ordinary socket errors on uwsgi.send? > > an exception would rise if write() fails for some reason > i mean BADFD, broken pipe etc. Or should i just intercept try: write() except: ... -- -------------------------------------------- Турнаев Евгений Викторович +7 906 875 09 43 -------------------------------------------- _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
