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]
