Filip Hanik - Dev Lists wrote:
In my personal opinion I am no longer sure a non blocking write is needed.
Ok.
async -> using more than one thread to do stuff
non blocking -> a method call which returns immediately without, well,
blocking
I think I did present understandable explanations, so if you don't
bother reading (as usual ...), I suppose I should stop wasting my time.
I agree a consensus should have been reached *on month ago* :)
we'd be in the same shoes we are today. I still think a pancake flipping
contest would be the way to go. although I might consider stone,paper
and scissors too.
No problem with that, feel free to consider it any way you like. What I
see in your response is that we actually agree on very little.
I'll try in order (one last time, most likely):
>> The connector should only care about IO, which only knows read and
>> write (and error, but obviously this is a special case, and I don't
>> see you registering for that).
> But the connector must care, if you do a CALLBACK, you must ensure that
> you are not spawning a 2nd thread if a READ comes in on the socket.
> otherwise, you are forcing the comet developers to synchronize,
> something in today's API, is done in such a way that if you do stuff on
> the Tomcat thread, you're safe.
Well, not really, the callback goes all the way to the poller, using the
same "add lists", which allows ensuring that events are not sent in a
concurrent way.
>> Actually, this is very simple to implement. Read is obvious. For
>> write, the algorithm for the flushBuffer method would be very similar
>> to what it is now, but if a write returns 0, leftover bytes would be
>> put in a ByteChunk. isWriteable, if called, will return false, and
>> place the socket in the poller with write notifications.
> that's not non blocking, that's a async write, and I could ten times
> more easier implement it in an AbstractCometProcessor.java, then having
> to fiddle with pollers and everything else down the chain.
> non blocking is a different concept than async.
I made an effort to explain in detail algorithms, and you come back with
definitions I do not understand and vague ideas (I have no idea what
would be implemented in AbstractCometProcessor).
> does not work either. isWriteable (when blocking) only is in effect for
> other threads, but write is not thread safe, so this method is useless
> then.
> and during an async write, you have the same issue, async writes still
> should only be done on one thread.
? Ok, so the plan is that there's only one thread attempting to write on
one particular connection. The lifeclyle seems very simple to me:
- check isWriteable
- write stuff
- repeat until isWriteable puts the socket in the add-write list for the
poller, and returns false
- wait until you get a write event before writing again on the connection
Since this is non blocking IO, it is indeed possible and recommended to
use a single thread for writing, thus maximizing scalability. If you
advocate a design where the user would write using multiple threads,
never sync anything, and hope it works, then I'd like to hear about a
use case first :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
