Re: JERI thread names

Mark Brouwer wrote:
> Bob Scheifler wrote:
>                                                 (Changes here would
>> also relate to larger changes to take advantage of 1.5-and-later
>> ThreadPoolExecutor).
>
> Hi Bob,
>
> What kind of advantages are you thinking of with 1.5-and-later
> ThreadPoolExecutor, or in other words do you believe the current
> concurrency utilities in com.sun.jini.thread need replacement.

I'm not too familiar with Jini/JERI/RMI internals but I feel a move to
java.util.concurrent ThreadPoolExecutor etc... would be beneficial in
that it would provide a single 'standard' model for ThreadPools
(particularly if you could inject your own configured Pools into the
objects that require them).

The main benefit of this approach is that it would allow you to define a
single policy (assuming you use the ThreadPoolExecutor elsewhere) for
thread management within a VM.

 From my point of view the control of Jini threading is rather opaque,
if it's possible using the model/api which comes with the JDK would make
thread management clearer.

Obviously there is a big risk in changing such things.

R.

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]