Peter Kümmel wrote: >> - all these graph backtraces i have seen up to now were going though >> converters. >> - when quickly went through export routines, all graph variables were >> local to the functions. >> - when studying possible conflict we both ended at the global converters >> object where is the conflict visible. > > Then we could lock in the global converters.
that was my lullaby for the whole time >> - do we agree that locks are not enough in the current version. > > No, I think the locked Graph (current trunk) is the solution to > the problem. What are your reasons to be skeptical about it? i got this feeling when you described conflict scenario on converters. which i imagined as something like 1: if (Q.empty) 2: Q.generate_paths(); 3: return Q.graph() 4... thread A checks 1 goes into 2, meanwhile thread B checks 1, also goes into 2. now because of locking insie graph, we do not crash anymore, fine. BUT we can can get wrong result - if A builds up different path than B then the routines for both A and B will retrive only one path insetad of two different paths. pavel
