>> It will be killed immediately, i am not sure that trapping IOError is a >> good thing, --reload-on-exception is for non-recoverable exception (like >> inconsistent db connections). > > I agree, sorry, that was a bad example. The real reason we have > reload-on-exception on is exactly what you mentioned: sometimes > SQLAlchemy raises while trying to tear down its session at the end of > a request, and then gets into a weird state. Looks like if we want to > keep using threads and this locking design, we'll need to turn off > reload-on-exception and figure out how to ensure the session teardown > always works.
Check if uwsgi locking framework could be useful for you > > I saw in a couple places on the list that --lazy-apps is recommended > when using SQLAlchemy. Why is that? If I understand fork() correctly > (which is dubious TBH), as long as you don't open any DB connections > during app initialization (which we don't), then preforking is ok. yes it is ok if you do not open file descriptors on it. > > Actually, just to make sure I understand preforking, is the master > basically a worker (i.e. it has the app loaded in memory) that never > serves requests and does all the master-y stuff like creating and > reloading workers, but otherwise has the same memory layout? And it > just fork()s when it creates or reloads a worker? Sorry if that was > incoherent, I know some C but haven't worked on anything as complex as > uWSGI. Your project is great, by the way! > yes, this is exactly how it works -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
