> >>Now Avalon utilities include a pooling implementation that is
> >>nothing like
> >>the Pool package in Commons. Should the new pooling package
> >>be moved in
> >>with that? And then what about the synchronization
> >>primitives? Do we know
> >>where they would go?
> >>
> >>
> >
> > What makes the Excalibur pool different/better? We start talking
> > about it to see what to do:
> > - Can we condense/refactor to just one?
> > - Do we need both?
> > - Is one better/more useful than the other?
>
>
> The pooling ideas are different. I am beginning to
> experiment with managed pools that perform sizing information
> in a separate thread. The experimentation happens in
> Excalibur's Scratchpad, not in the released jar.
>
> There are many things to discuss.
>
>
> >
> > We just need to start talking about it :)
> > All of this is just an email thread away ;-)
>
>
> Ok, let me talk with the Avalon committers, to see about doing this.
Excellent! I am on avalon-dev and apps, so I will be listening ;-)
>
>
> >
> > IMHO the synch primitives would go with the threading
> proposal in the
> > sandbox. Do your primitives look like these? How are they
> different?
>
>
> Actually, what is in the Threading project is mostly queue
> classes... something that I am working on and have a very
> cool implementation of. (I.e. how about transactional
> enqueuing, etc.).
>
> There is a Semaphore and Mutex object in the commons project,
> but no DijkstraSemaphore (we have both), ReadWriteLock,
> ThreadBarrier, or Sync interface.
>
> The Excalibur event package has the queue classes and
> implementations. The Queues have been tested threadsafe and
> can perform a complete enqueue/ dequeue pair in a few
> nanoseconds (based on average of 11 million enqueue/dequeue
> ops). Further, the Queues have transactional enqueuing
> capabilities that work like this:
>
> PreparedEnqueue stack = queue.prepareEnqueue( elements ); //
> elements is an array
> //
> of QueueElement objects
>
> if ( condition == ok )
> {
> stack.commit();
> }
> else
> {
> stack.abort();
> }
>
> There is more, but that is one point of distinction
Sounds like yours are more advanced or not competing, so it makes sense
to bring them in to 'round out' the threading proposal. It would also
give the threading proposal a boost in that it would actually be used in
a public, visible product.
>
>
> >
> > I am actually excited about commons and Avalon/Excalibur
> working more
> > closely to each other. Sam came in with Gump and managed
> to get the
> > APIs to stabilize, now we need another level of
> cooperation. I think
> > that this can make it happen.
>
>
> I would like to see this happen, but am feeling this out step by step.
>
Perfectly acceptable.
Look forward to working to make all of our lives easier.
Scott
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
