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
thread.
non blocking -> a method call which returns immediately without, well,
blocking
yes
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 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).
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
