users@grizzly.java.net

Re: Fwd: WG: Re: WG: Re: WG: Re: WG: Re: Asynchronous Request Processing with TCPIP

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 08 Jul 2008 16:30:47 -0400

Salut,

John ROM wrote:
> Hi Jeanfrancois,
> I think the right way to go if one wants other threads beside workerthread to use
> Context is to give Context knowledge of what threads are using Context.
> Context then gets recycled when the thread calling Context.recyle is the last one using it.
> So the contract would be if one Thread wants to use Context it has to register and
> afterwords unregister with Context......
>
> What do you think?

That's doable, although it will be quite complicated to get the list of
thread that are referencing that object. Or do I miss something?

Thanks!

-- Jeanfrancois



>
>
> Salut,
>
> John ROM wrote:
>> Hi Jeanfrancois,
>>
>> So I really now think that I just should and do a :
>> (in com.sun.grizzly.filter.MessageDispatcher)
>>
>> final Context copyContext=workerCtx.getController().pollContext(workerCtx.getSelectionKey());
>> workerCtx.copyTo(copyContext);
>>
>> // and then when I am finished
>> //
>> copyContext.getController().returnContext(copyContext);
>
> What about this proposal:
>
> When calling suspend/resume, we never recycled the object. If an
> implementation wants to recycle those, we can either add a new API like
> recycleAndReturn(), which will internally call the
> controller.returnContext().
>
> What peoples thinks?
>
> A+
>
> -- Jeanfrancois
>
>
>
>> Many Greetings John
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
>