[robert]
> In very rare cases a program crashes (hard to reproduce) :
>
> * several threads work on an object tree with dict's etc. in it. Items
> are added, deleted, iteration over .keys() ... ). The threads are "good"
> in such terms, that this core data structure is changed only by atomic
> oper
> robert wrote:
> Meanwhile I think this is a bug of cPickle.dump: It should use .keys()
> instead of free iteration internally, when pickling elementary dicts.
> I'd file a bug if no objection.
What should happen if there's a delete between the time the .keys()
runs and the time that the deleted
You can also *almost* do it with a tracehook that blocks until released
by another thread. See http://projects.amor.org/misc/wiki/PyConquer for
the tool I'm sporadically working on that does that (in an effort to
test all possible execution paths). The only limitation is that trace
functions aren't
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
...
> This is vaguely possible using sys.setcheckinterval() now, although one
> has to pick a ridiculously large number and hope that the atomic operation
> takes fewer than that many opcodes.
>
> Spelling "do not switch threads" as sys.setcheckint
On 12 Mar 2006 17:56:37 -0800, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>Thinking about future directions for Python threading, I wonder if
>there is a way to expose the GIL (or simply impose a temporary
>moratorium on thread switches) so that it becomes easy to introduce
>atomicity when need
[robert]
> In very rare cases a program crashes (hard to reproduce) :
>
> * several threads work on an object tree with dict's etc. in it. Items
> are added, deleted, iteration over .keys() ... ). The threads are "good"
> in such terms, that this core data structure is changed only by atomic
> oper
robert si è profuso/a a scrivere su comp.lang.python tutte queste
elucubrazioni:
> Yes, a "backup" / autosave while all threads are running. It doesn't
> matter if 'before' of 'after' another item has been added/deleted
> atomically.
But it does matter if the autosave happens *while* an item i
Tim Peters wrote:
> [robert]
>
>>...
>>PS: how does ZODB work with this kind of problem? I thought is uses cPickle?
>
>
> It does. Each thread in a ZODB application typically uses its own
> connection to a database. As a result, each thread gets its own
> consistent view of database objects,
EleSSaR^ wrote:
> robert si è profuso/a a scrivere su comp.lang.python tutte queste
> elucubrazioni:
>
>
>>own deepcopy: thus, do you already know if the existing deepcopy has the
>>same problem as cPickle.dump ?(as the problem araises rarely, it is
>>difficult for me to test it out)
>
>
[robert]
> ...
> PS: how does ZODB work with this kind of problem? I thought is uses cPickle?
It does. Each thread in a ZODB application typically uses its own
connection to a database. As a result, each thread gets its own
consistent view of database objects, which can (and routinely does)
vary
robert si è profuso/a a scrivere su comp.lang.python tutte queste
elucubrazioni:
[cut]
P.S.
I'm very bad at threaded programming. Please verify any of my suggestions
^_^
--
EleSSaR^ <[EMAIL PROTECTED]>
--
Togli .xyz dalla mia email per contattarmi.
--
http://mail.python.org/mailman/listinfo/
robert si è profuso/a a scrivere su comp.lang.python tutte queste
elucubrazioni:
> own deepcopy: thus, do you already know if the existing deepcopy has the
> same problem as cPickle.dump ?(as the problem araises rarely, it is
> difficult for me to test it out)
I don't know the exact specs
robert <[EMAIL PROTECTED]> wrote:
...
> 99.99% no. I would have to use a lock everywhere, where I add or remove
> something into a dict or list of the struct. Thats not the purpose of
> big thread locks. Such simple operations are already atomic by the
> definition of Python - and thanks to the
EleSSaR^ wrote:
> robert si è profuso/a a scrivere su comp.lang.python tutte queste
> elucubrazioni:
>
> [cut]
>
> I don't know what's your code like, but a similar error occurred in some of
> my software and it was my fault indeed. I think you should either use a
> lock, or implement a deepcop
Felipe Almeida Lessa wrote:
> Em Sáb, 2006-03-11 às 12:49 +0100, robert escreveu:
>
>>Meanwhile I think this is a bug of cPickle.dump: It should use .keys()
>>instead of free iteration internally, when pickling elementary dicts.
>>I'd file a bug if no objection.
>
>
> AFAICS, it's a problem w
robert si è profuso/a a scrivere su comp.lang.python tutte queste
elucubrazioni:
[cut]
I don't know what's your code like, but a similar error occurred in some of
my software and it was my fault indeed. I think you should either use a
lock, or implement a deepcopy method of your own.
--
EleSSa
Em Sáb, 2006-03-11 às 12:49 +0100, robert escreveu:
> Meanwhile I think this is a bug of cPickle.dump: It should use .keys()
> instead of free iteration internally, when pickling elementary dicts.
> I'd file a bug if no objection.
AFAICS, it's a problem with your code. You should lock your objec
robert wrote:
>
>> Is a copy.deepcopy ( -> "cPickle.dump(copy.deepcopy(obj),f)" ) an
>> atomic opertion with a guarantee to not fail?
>>
>> Or can I only retry several times in case of RuntimeError? (which
>> would apears to me as odd gambling; retry how often?)
>
>
> For an intermediate so
> Is a copy.deepcopy ( -> "cPickle.dump(copy.deepcopy(obj),f)" ) an
> atomic opertion with a guarantee to not fail?
>
> Or can I only retry several times in case of RuntimeError? (which would
> apears to me as odd gambling; retry how often?)
For an intermediate solution, I'm playing roulette
In very rare cases a program crashes (hard to reproduce) :
* several threads work on an object tree with dict's etc. in it. Items
are added, deleted, iteration over .keys() ... ). The threads are "good"
in such terms, that this core data structure is changed only by atomic
operations, so that t
20 matches
Mail list logo
