fumanchu wrote:
If you used a Queue, it wouldn't be the container itself; rather, it
would be a gatekeeper between the container and consumer code. A
minimal example of user-side code would be:
class Request:
def __init__(self, op, data):
self.op = op
self.data = data
I get what you're saying fumanchu (or should I say Robert?).
I've been working and reworking this code. It's in a lot better shape
now (although I hestitate to keep flooding the conversation with each
iteration of the file). At the level this app should be operating, I
doubt I'll hit performance
mwt wrote:
One thing I'm still not sure about -- and I suspect that there is no
right answer -- is the fact that although I am writing the code in
Python, the idiom is purely Java. Having my data bucket in the form of,
essentially, a bean with setters and getters, and each method
surrounded
The Queue won't work for this app, because it removes the data from the
Queue when you query (the way I understand it).
--
http://mail.python.org/mailman/listinfo/python-list
If you used a Queue, it wouldn't be the container itself; rather, it
would be a gatekeeper between the container and consumer code. A
minimal example of user-side code would be:
class Request:
def __init__(self, op, data):
self.op = op
self.data = data
self.reply =
Hi. I'm reworking a little app I wrote, in order to separate the data
from the UI. As a start, I wanted to create a iron-clad data recepticle
that will hold all the important values, and stand up to being queried
by various sources, perhaps concurrently. In all likelihood, the app
will never need
There's nothing really *broken* jumping out at me. The last three
methods (set_value, set_data, and clear_data) probably don't need a
mutex, since they will each have their own frame, and the operations
are atomic. If that makes no sense, Google for Python GIL ;). If you
just returned a value from
mwt enlightened us with:
I'm reworking a little app I wrote, in order to separate the data
from the UI.
Good idea.
As a start, I wanted to create a iron-clad data recepticle that will
hold all the important values, and stand up to being queried by
various sources, perhaps concurrently.
Why
fumanchu: Interesting. I'm trying to understand atomicity. Also, since
I want this class to work using the Observer pattern, I've complicated
things, as shown below. I'll look into Dejavu for persistence (although
most of the basic values are persisted elsewhere, so this app will
mainly need only
Well, thank the gods for unit testing. Here's the fah_data module with
fewer errors:
import copy, threading, observable
class FAHData(observable.Observable):
The data model for the [EMAIL PROTECTED] monitor.
def __init__(self):
observable.Observable.__init__(self)
mwt wrote:
def get_data(self, key):
Returns a COPY of key data element.
try:
self.mutex.acquire()
return copy.deepcopy(self.data[key])
finally:
self.mutex.release()
self.mutex.acquire() should be outside the try block, like
I didn't say that right. As long as you are using deepcopy (or any
operation which might iterate over the keys or values in self.data),
your setter methods need that mutex, *and* it should probably be a
threading.Lock, not an RLock, just in case that iteration ends up
mutating the dict somehow.
12 matches
Mail list logo
