Salut,
Oleksiy Stashok wrote:
>> Oleksiy Stashok wrote:
>>> Hi,
>>> basically we will not use Executors directly,
>>> but Grizzly new ThreadPool interface will extends ExecutorService.
>>
>> I think we should let peoples drop their Executors in 1.9.0...the only
>> restriction we should impose is the ThreadFactory, which needs to
>> create WorkerThreads.
> I think Executor is not actually ThreadPool, it's more general abstraction.
> Executor doesn't have info on how much threads it uses (if uses),
> min/max threads number, start/stop lifecycle methods. On one side it
> could be ok, but on another side we can throw away all our ThreadPool
> configuration, because they will not be applicable in general way.
>
I think I would still go that route.
> ThreadPool interface we propose is simple enough (IMHO), what it
> requires additionally to ExecutorService, is just min/max threads,
> start/stop methods and name.
>
> So, I think we can have ThreadPool interface, and if someone wants to
> use own ExecutorService - it will be quite easy to make a wrapper.
Well, If we drop Pipeline then we shouldn't add another Wrapper. We
should just let peoples drop the Thread Pool IMO. My motivation to drop
Pipeline is to allow external Executors can be dropped as it as.
A+
-- Jeanfrancois
>
> WBR,
> Alexey.
>
>
>
>
>>
>>
>> What do you think?
>>
>> -- Jeanfrancois
>>
>>
>>> So it will be possible to use Grizzly's ThreadPool as general Executor.
>>> WBR,
>>> Alexey.
>>> On Nov 27, 2008, at 16:01 , Jeanfrancois Arcand wrote:
>>>> Hi,
>>>>
>>>> Alexey and I thinks that it might be time to drop the Pipeline
>>>> interface and directly expose Executors. In order to do that, we
>>>> will break backward compatibility with 1.8.x for application that
>>>> were using this interface. I do suspect we will not break a lot of
>>>> application, but just to make sure, I would like to propose the
>>>> following:
>>>>
>>>> (1) Assuming we don't see any performance regression (I've never
>>>> trusted the Concurrent's thread pool and demonstrated many time our
>>>> was faster), we switch to Executors
>>>>
>>>> (2) If a critical bug is found with 1.8.x users, we continue
>>>> maintaining the 1.8.x branch so peoples doesn't have to change anything
>>>>
>>>> Alexey has a patch that I will try and test to make sure no
>>>> performance regressions occurs.
>>>>
>>>> What peoples think?
>>>>
>>>> A+
>>>>
>>>> -- Jeanfrancois
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>