On May 12, 11:40 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > - in __getitem__, does it release the lock after returning the item?
>
> Yes, it does.
>
> > - wouldn't it be better to use threading.RLock, mutex, ... instead?
>
> Better in what sense? Performance-wise? Semantically? Performanc
> - in __getitem__, does it release the lock after returning the item?
Yes, it does.
> - wouldn't it be better to use threading.RLock, mutex, ... instead?
Better in what sense? Performance-wise? Semantically? Performance-wise,
the best thing would be to do
safe_dict = dict
because the builtin
On May 10, 8:25 pm, [EMAIL PROTECTED] wrote:
instead:
> class safe_dict(dict):
there should be:
class safe_dict(object):
--
http://mail.python.org/mailman/listinfo/python-list
On May 10, 3:57 pm, Duncan Booth <[EMAIL PROTECTED]> wrote:
> IMHO you are probably best to write a thread-safe class which uses an
> ordinary dict (and has a nicely limited interface) rather than trying to
> produce a completely thread-safe dict type.
thanks, sounds good!
but that again:
from
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>>- would I need to override another methods e.g. update() or items() in
>>order to remain thread-safe or is this enough?
No, you'll need to protect almost everything. items may be safe. update,
clear, get, has_key, pop, and setdefault all need a lo
Jean-Paul Calderone schrieb:
> On 10 May 2007 05:45:24 -0700, [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> please consider the following code:
>>
>>
>> from __future__ import with_statement
>>
>> class safe_dict(dict):
>>def __init__(self, *args, **kw):
>>self.lock = threading.Lock()
>>
On 10 May 2007 05:45:24 -0700, [EMAIL PROTECTED] wrote:
>Hi,
>
>please consider the following code:
>
>
>from __future__ import with_statement
>
>class safe_dict(dict):
>def __init__(self, *args, **kw):
>self.lock = threading.Lock()
>dict.__init__(self, *args, **kw)
>def __g
