[perl #19349] [PATCH] mark PMCs - take #2
Dan Sugalski
>Here is another approach, to finally unify the marking routines:
>- next_for_GC remains what it is
>- instead of current_end_of_list and a return value, mark_used() uuses
> a file static mark_ptr. As we don't have recursive DOD runs, this
> ought to be safe.
Nope. Threads. Two interpreters can be DODing at the same time.
Static variables aren't tenable for much of anything with threads...
:(
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Nicholas Clark
> At 1:50 PM +0000 12/22/02, Leopold Toetsch (via RT) wrote:
> >Here is another approach, to finally unify the marking routines:
> >- next_for_GC remains what it is
> >- instead of current_end_of_list and a return value, mark_used() uuses
> > a file static mark_ptr. As we don't have recursive DOD runs, this
> > ought to be safe.
>
> Nope. Threads. Two interpreters can be DODing at the same time.
> Static variables aren't tenable for much of anything with threads...
> :(
Unless protected by a mutex.
I have now read the programming POSIX threads book. I take it that makes me
a fully qualified l33t threads d00d who knows everything.
How much of a speed impact could it be to serialise DOD runs between threads?
Presumably 1 thread doing a DOD run could actually manage to free up enough
memory to make both happy?
Nicholas Clark
Dan Sugalski
If the interpreters are reasonably separate, then one won't affect
the other, except in cases where the system has exhausted the memory
available to the process, so there's not a huge reason to do this.
Also, it is a choke point. Since the interpreters are generally
separate, the better place for this is in the interpreter structure.