trengove at econdata.com.au
Tue May 8 13:34:46 EST 2001
Stéphane, I would be great if you could find time to look at this. I have been doing some more investigating, trying to understand just what is going on. As I mentioned in my previous message, Py_BEGIN_ALLOW_THREADS is called in the request object's write() method, so thread switching could occur here. But thread switching should still occur in any case inside the main Python interpreter loop. To test this, I tried the following script from mod_python import apache import thread counter = None LOOPLIMIT = 1000000 def handler(req): global counter counter = 0 for i in range(0,LOOPLIMIT): counter = counter + 1 req.content_type = "text/plain" req.send_http_header() req.write("%d: %d\n" % (thread.get_ident(),counter)) return apache.OK If I load this page once, I get a value of 1000000 back, as expected. If I load the page from two clients "simultaneously" (or as fast as I can activate each one), I get something like Client 1 1908: 1200128 2016: 1354557 2024: 591402 Client 2 2004: 1698384 2012: 1800311 2028: 1205627 This is for three repetitions of the page load. As you can see, the Python interpreter is definitely switching between threads, and producing crazy results for the global counter variable, which is not protected by any lock. This is all as expected. The puzzle is why the thread switching inside the request object's module should be causing some problem, if that is indeed where the trouble lies. I am wondering whether there is something in the request object structure which is not totally thread-safe. Incidentally, if I run enough repetitions of this test setup, I can eventually get a situation where one thread crashes, and the other thread (just at this point) returns a value like 632: 1515843<LF>568: 1572286 that is TWO thread IDs in the one message -- the write buffer of one thread is being appended to by the other, somehow. Some food for thought. Chris >I think this is true for *nix, but on windows, >you *must* use a multithreaded python. > >I'll try to have a look at your issue, but I've very >few time available these days.