> Adding data locking shouldn't be too complicated, but is it necessary? > The bytes object does support locking the buffer in place; isn't that > enough? It means someone evil could still produce a phase error by > changing the contents while you're looking at it (basically sabotaging > their own application) but I don't see how they could cause a segfault > that way.
I'm sure the BerkeleyDB library is not expecting the data passed in as a lookup key to change mid database traversal. No idea if it'll handle that gracefully or not but I wouldn't expect it to and bet its possible to cause a segfault and/or irrepairable database damage that way. The same goes for any other C APIs that you may pass data to that release the GIL. > Even if you really need the LOCKDATA feature, perhaps you can check in > a slight mod of your code that uses SIMPLE for now -- use a macro for > the flags that's defined as PyBUF_SIMPLE and add a comment that you'd > like it to be LOCKDATA once bytes support that. > > That way we have less code in the tracker and more in subversion -- > always a good thing IMO. yeah i have it almost working in SIMPLE mode for now, i'll check it in soon. its no worse in behavior than the existing bytes object using code currently checked in. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
