Jonathan Ellis wrote: > On Mon, 15 Aug 2005 15:46:19 -0500, "Ian Bicking" <[EMAIL PROTECTED]> > said: > >>>That is a design decision which not all frameworks (or other consumers >>>of our session lib) might share. Apparently, given the current Python >>>session modules out there, it's common to survive without caring? I know >>>Mike Robinson has worked many long nights trying to make a session >>>module for CherryPy which can consistently pass simple hit-counter >>>tests. ;) Personally, I'd like to pursue an MROW solution. >> >>In practice race conditions are very uncommon. Simultaneous requests >>from the same session are uncommon, since what few simultaneous requests >>that occur are likely to be for boring resources like images. If you >>have an image bug on a page that also writes the session, maybe you'd >>have a problem. I'd be okay saying "don't do that" because usually >>people don't do that, so it's not very compelling. > > > I wouldn't be okay with non-threadsafe sessions.
Non-threadsafe in what manner? Certainly they should be usable in threaded environments, and should never blow up or anything. I just assume that. The question is whether, if there's two concurrent writers (threaded or multiprocess), they should be serialized (and how), or if one of them simply clobbers the other. Threads or multiprocess, it's really the same issue. Except perhaps for isolation -- threads could *potentially* see changes in other threads, but that's not possible for multiple processes. So probably they should always be isolated; not a big deal, but something to consider. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
