>
> 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 :)
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.
> 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
>