users@grizzly.java.net

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

From: John ROM <snake-john_at_gmx.de>
Date: Mon, 07 Jul 2008 18:35:31 +0200

Hi Jeanfrancois,

> Why do we need to synchronize here? I think as soon as you invoke the
> suspend method, the developer should take care of making a single thread
> is manipulating the new object.

maybe I am just misusing the concept.

When I suspend a Context I want to say no one should recycle Context
until Context.resume is called.


So what can happen is :

Business Thread calls Context.resume() and then line
isSuspended = false;

and now scheduler makes WorkThread the current Thread so

WorkThread calls ContextTask.recycle.isSuspended() which is false and
now both recycle ... which is not good (-:

On the other hand in my protocol many business Threads might use the same
Context because many messages can be in one byteBuffer and in my code I might
be calling resume() twice or more times on the same context.

I do not want that continuousExecution Logic is changed because I like the
performance I gain by staying on the same WorkerThread and calling
ReadFilter again.....

So maybe I should stick to copying Context....


Was I able to explain my usecase?

Many Greetings
John




-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx