2009/2/2 John ROM <snake-john_at_gmx.de>
> Gustav,
> > John,you managed to write quite a lot text, without answering any of my
> > questions.
> > baby talk like ((-: is something you can keep for yourself please,
> > especially when your using it to negate positive worlds in the same
> > sentence.
> >
> >
> > 2009/2/1 john <snake-john_at_gmx.de>
> >
> > > On Sun, 2009-02-01 at 13:44 +0100, gustav trede wrote:
> > > Hi Gustav,
> > > great that you are looking also at Slab Memory Management.((-:
> > > I think Alexey and me could really use some help ((-:
> > >
> > > > Hello,
> > > >
> > > > SlabPoolImpl , all public methods share the same lock.
> > > > All memory allocation are performed inside the synchronized
> > > > context...
> > > >
> > > > I would be happy to fix the implementation , but would like to get
> > > > answers to these question first:
> > >
> > > >
> > > > If there is a need of truly exact size limits ? ,if so all set size
> > > > changing operations will be forced to be synchronized, no need for
> > > > concurrenthashmap.
> SlabPoolImpl does not have a concurrenthashmap and no set size operations.
> Which class are you referring to?
we all know how the current SlabPoolImpl is implemented.
im talking about possible ways to re implement the class.
I had 2 questions that is still unanswered,
im not going to put more energy into geting basic communication to work.
i have no further interests in the slab memory management.