Salut,
Oleksiy Stashok wrote:
>>
>> Sebastian Dehne wrote:
>>>> The problem is that some Fitler may decide to detach a ByteBuffer
>>>> and not return in to WorkerThread.
>>>> Actually we need to check (recreate if required) BB each time before
>>>> a new task to be executed on a WorkerThread.
>>>> So create BB just once, when Thread is going to be created will not
>>>> work :(
>>> Good point. It also shouldn't be a threadPool's resposibility to
>>> manage the byteBuffer.
>>
>> Well, at least the ThreadPool must use our Threadfactory, as it will
>> not work if it doesn't.
>>
>> Alexey: It is still unclear to me that I'm wrong. The WorkerThread can
>> always make sure, when it execute, that it's BB is not null. Actually
>> this is what WorkerThread were doing until recently ;-) So I do think
>> my proposal will perfectly works ;-)
> WorkerThread can not make sure of that :)
Before executing the task, they can certainly do it ;-) This is how is
was done before we switch to ExecutorServices:
> public WorkerThreadImpl(Pipeline<Callable> pipeline, String name,
> Runnable runnable, int initialByteBufferSize){
> super(threadGroup, runnable, name);
> target = runnable;
> this.pipeline = pipeline;
> setDaemon(true);
> this.initialByteBufferSize = initialByteBufferSize;
> }
>
> /**
> * Execute a {_at_link Task}.
> */
> @Override
> public void run(){
> if (byteBuffer == null){
> byteBuffer = ByteBufferFactory.allocate(byteBufferType,
:-)
> Currently WorkerThread just runs ThreadPool's internal task and runs it
> forever, or until ThreadPool will decide to stop the thread.
> WorkerThread doesn't even have own run method implemented, it derives it
> from Thread.
> So possible solution could be in notifying WorkerThread from ThreadPool
> each time a new task is going to be executed. This way we will move
> Buffer allocation logic from ThreadPool to WorkerThread.
I agree :-) Any solution to the current issue is good :-)
A+
-- jeanfrancois
>
>
>> Image I have a single threadPool which I use for
>>> multiple applications (also grizzly). With the current design, each
>>> thread of this pool will get a byteBuffer at some point in time.
> Right. Having ByteBuffer for each thread let's us decrease a number of
> ByteBuffer allocations, which is quite expensive.
>
>
>>> A better way is to detach the byteBuffer from a thread when is it not
>>> needed and re-attach it again once a certain thread is going to do
>>> some work for grizzly.
>>
>> Hum, performance wise, the idea is to avoid the synchronization of
>> putting the bb inside a pool and then getting back once needed. That's
>> the hole idea of attaching a thread to the WorkerThread.
> And pooling ByteBuffer will not help neither with memory consumption
> (ByteBuffers just will be gathered in pool instead not in workerthread)
> nor with performance (cost of synchronization).
>
> Thanks.
>
> WBR,
> Alexey.
>
>>
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>>> Seb
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>