Would it make sense to reuse some of the facilities in util.concurrent
package from Doug Lea ?
I think PooledExecutor<->Executor does something similar to what you may
want. Maybe the implementation could wrap PooledExecutor internally.
What do you think ?
Harmeet
----- Original Message -----
From: "Peter Donald" <[EMAIL PROTECTED]>
To: "Avalon Development" <[EMAIL PROTECTED]>
Cc: "Avalon Development" <[EMAIL PROTECTED]>
Sent: Sunday, May 13, 2001 5:40 PM
Subject: RE: The release is official
> At 04:19 13/5/01 +0100, Paul Hammant wrote:
> >How do other Avlalon projects
> >refresh/handle the underlying Avalon jar files?
>
> I have set it up so that Avalon has "install" targrets that install them
> into a central location - "/opt/apps/cjan" for me. Then all my dependent
> projects pick up the jars from there. I would really like to remove jars
in
> CVS eventually - though we will have to wait for cjan/jjan for that ;)
>
> >> >scratchpad
> >> >==========
> >> >
> >> >Is this code we're unsure about? Is it designed to be move back to
core
> >> jars or consigned to the scrapheap?
> >>
> >> Parts scrapheap (Primes/Circuit/DependencyGraph) unless there is a
deman
> >> for it. The other parts are waiting a rewrite (ie proxy/thread). Then
there
> >> is the "other" stuff that I don't know about or hasn't seen
> deman/testing etc.
> >
> >I'm using ThreadPool. I was a little confused for a while as it is
> mentoined in BlockContext.
>
> Heres a description of upcoming changes from another mail.
>
> --------------------------------------------------------------
> Unfortunately that doesn't cut it as usually you need to have Thread
> implement a particular class so it replaces itself back in pool after it
> has done a run() on it' client. The way I am just about to redesign the
> Avalon thread pool is as follows
>
> interface ThreadPool
> {
> void executeAndWait( Runnable work ) throws ThreadException;
> void executeAndWait( Executable work ) throws ThreadException;
>
> ThreadControl execute( Runnable work );
> ThreadControl execute( Executable work );
> }
>
> class ThreadException
> {
> ...
> Throwable getRootCause() { ... }
> ...
> }
>
> interface ThreadControl
> {
> void interupt() throws Exception;
> boolean isValid();
> boolean isFinished();
> Throwable getThrowable();
> }
>
> //Method gets called for thread hook right before you dispatch work
> interface ThreadHook
> {
> void setupThread() {}
> }
>
> executeAndWait is useful when you are using the pool to cross
> thread/protection boundaries (Very very useful in writing software like
> tomcat/james/Avalon-phoenix).
>
> execute returns a control so you can control all the important features of
> thread directly.
>
> ThreadHook.setupThread() is called right before a set of work is
dispatched
> and usually used to set name of thread, contextClassLoader and any other
> thread local variables.
>
> All other thread features (ie priority, whether thread is a daemon thread,
> etc) are determined by pool.
>
> I haven't found any places where the above design won't work - what do you
> think about it?
> --------------------------------------------------------------
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
