tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Proposed simplification of CometEvent
Date Fri, 08 Jun 2007 15:11:14 GMT
Remy Maucherat wrote:
> 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
and that is what you are proposing, to dispatch the write to the poller 
> 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.
throwing your hands in the air and saying you're not going to waste your 
time, is in your personal interest only and you are of course welcome to 
do anything you wish. Throwing in derogatory statements like the one 
above, wont help you achieve your goal, it will only risk you being 
taken less seriously, and it doesn't benefit you nor the community.
>>> 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.
yes, so you are including the connector, and that was my point. you 
argued that callback had nothing to do with the connector, only care 
about IO events.
> >> 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, 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).
ok, you suggest that a non block write is simply a dispatch of the 
writing to the poller in the event of the data written didn't fit in the 
network buffer, that sounds like multiple threads are indeed involved. 
So this is just a terminology misunderstanding. What you are explaining 
is similar to the SEND_FILE way of doing it, there is still a thread on 
our side involved in writing the data. I do understand your solution, 
and it would still work with my API.
it would be like this
a) check isWriteable
b) write stuff possibly goto f)
c) check isWriteable, if true goto b) else goto d),
d) event.register(OP_WRITE)
e) wait for a WRITE event to come in
f) done

in your API, you are forcing the WRITE event notification, I may just 
not be interested in it, and that is why I like the trunk API better, it 
is event driven and it is the developer who controls what notifications 
are going to be coming or not. Since a WRITE event does take a thread 
out of the thread pool, that may not be desired.
That is one of the main reason I like the trunk API, it gives a clear 
understanding of what events I'm about to receive. and yes, ERROR/END 
are an exception today, but that can be adjusted if one feels like it, 
personally I'm ok with those exceptions.
> > 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message