----- Original Message ----- From: "Leopold Toetsch" <[EMAIL PROTECTED]> To: "Peter Haworth" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, September 03, 2003 4:38 PM Subject: Re: [RfC] vtable->dump
> Peter Haworth <[EMAIL PROTECTED]> wrote: > > On Wed, 3 Sep 2003 09:24:22 +0200, Leopold Toetsch wrote: > >> One general traverse() vtable is just the simpler interface IMHO. > >> > >> Running through each aggregate just once plus updating a seen_hash seems > >> simpler and faster to me and doesn't have any negative impact on PMC size > >> and DOD speed. > > > And also makes it threadsafe? If a shared PMC is frozen simultaneously by > > two threads under Dan's scheme, will the right thing happen? I can't help > > being worried about interactions between any two operations which use > > flags on the PMCs to makr their progress (such as freezing and DOD, or > > two freezes). > > Good question. We don't have threads yet, they might exist somewhere > inside Dan's brain, though. > > What I know (or think to know is): > > As in Dan's scheme next_for_GC is inside the PMC and used as flag/id for > freeze, this can't be threadsafe (If one thread has visited a PMC its > next_for_GC will be set, a second thread would write just the PMC id, > because the next_for_GC isn't cleared). > > So all these operations (clone too) would have to acquire a global lock > first AFAIK. > > For my scheme I don't see *this* kind of problems (all state is kept in > automatic variables in the interpreter). Albeit I don't like to know > what happens, when a shared aggregate gets sorted on one side and the > other is freezing it in the meanwhile. > > leo just a thought: aren't shared objects/data/whatever protected by a mutex? To me, that's the obvious solution for accessing shared data. As I said, just a thought. Klaas-Jan
