Salut,
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 ;-)
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.
>
> 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.
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
>