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]
