- 22 Jan, 2003 5 commits
-
-
Guido van Rossum authored
Add socket-name to runner conf template. Check that the port isn't in use already.
-
Guido van Rossum authored
-
Guido van Rossum authored
-
Barry Warsaw authored
-
Chris Withers authored
-
- 21 Jan, 2003 3 commits
-
-
Guido van Rossum authored
-
Barry Warsaw authored
acts more like what happens when you commit new object revisions using the higher level interface.
-
Barry Warsaw authored
-
- 20 Jan, 2003 14 commits
-
-
Fred Drake authored
- make it easier for an admin to configure logging levels (by making the defaults more sane) - refactor the tests a little, in preparation for more tests
-
Fred Drake authored
- remove methods that aren't needed - rename "resolved" to "instance" for readability
-
Fred Drake authored
-
Fred Drake authored
- de-tabify everything
-
Guido van Rossum authored
-
Guido van Rossum authored
_deadline to None, to prevent reporting the same timeout more than once. Added a helpful comment too. :-)
-
Barry Warsaw authored
intent according to the comment.
-
Guido van Rossum authored
-
Guido van Rossum authored
- Get rid of _lock() and _unlock(); _lock() is inlined, and so is _unlock(), after factoring out some common code at the end of tpc_begin() and tpc_end(). - In the refactored _unlock() code, only call self.timeout.end() if self.locked was actually set. In the TimeoutThread class: - Add some comments. - Add some assertions. - Get rid of the stop() method; we're a daemon thread so we'll be killed anyway; close_server() is only used from the test suite. - Switch from using a lock + an event to a condition variable. Be religious about doing stuff only while holding the lock. - Inline the timeout() function; it shouldn't reacquire the lock anyway. --Guido & Jeremy
-
Barry Warsaw authored
earlier in the loop. Basically, once we've got a tid from the transaction record, we check it against our stop tid, and we check the status looking for a 'c' flag.
-
Barry Warsaw authored
the middle of a transaction. This test isn't totally helpful in its own right, but run it with logging and you'll see the bogus warning (before the fix is applied).
-
Florent Guillaume authored
Fixed to correctly munge sys.path.
-
Guido van Rossum authored
that we can get distutils install to munge the #! line to insert the proper Python executable file name. (/usr/local/bin/python would work too, but may not be the Python version that you intended to use, so IMO it's better to require that you use an explicit Python interpreter when invoking the scripts before they are installed.
-
Fred Drake authored
-
- 18 Jan, 2003 2 commits
-
-
Guido van Rossum authored
runzeo.py lives -- that didn't work when runzeo.py is installed in /usr/local/bin.
-
Guido van Rossum authored
-
- 17 Jan, 2003 16 commits
-
-
Fred Drake authored
-
Fred Drake authored
activities these days.
-
Fred Drake authored
-
Fred Drake authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Fred Drake authored
-
Jeremy Hylton authored
-
Guido van Rossum authored
-
Fred Drake authored
-
Fred Drake authored
-
Jeremy Hylton authored
Closes SF bug #659068.
-
Jeremy Hylton authored
-
Guido van Rossum authored
-
Shane Hathaway authored
This change adds a new method, setLocalTransaction(), to the Connection class. ZODB applications can call this method to bind transactions to connections rather than threads. This is especially useful for GUI applications, which often have only one thread but multiple independent activities within that thread (generally one per window). Thanks to Christian Reis for championing this feature. Applications that take advantage of this feature should not use the get_transaction() function. Until now, ZODB itself sometimes assumed get_transaction() was the only way to get the transaction. Minor corrections have been added. The ZODB test suite, on the other hand, can continue to use get_transaction(), since it is free to assume that transactions are bound to threads.
-
Tim Peters authored
+ Transaction T1 deletes some of the keys in bucket B, but not all of the keys. + Transaction T2 deletes (exactly) the keys in B that aren't deleted by T1. The version of B each transaction sees is then non-empty, but conflict resolution creates an empty bucket. However, conflict resolution doesn't have enough info to unlink an empty bucket from its containing BTree correctly. The result is that an empty bucket is left in the BTree, which violates a BTree invariant. The most probable symptom is a segfault, when later & unrelated code tries to access this bucket: an empty bucket has NULL pointers where the vectors of keys and values should be, and accessing code tries to dereference the NULL pointers. I don't know that this error has been seen in real life. It was provoked by a randomized multithreaded simulation program that was trying to provoke errors. This error was provoked frequently by that program; no other kinds of errors have come out of it.
-