On 4/18/11 12:13 PM, Steve Ulrich wrote:
D4n Outlook. This time with a better quotation... I hope
Emmanuel Lecharny [mailto:[email protected]] wrote
Fair enough. But we can mitigate this risk on the IoProcessor too, by
pulling out of the queue all the messages for a session, until the
socket can't accept any more writing. Something like :
while () {
WriteReqest message = queue.get();
Session session = message.getSession();
Channel channel = session.getChannel();
while ( channel is ready for write) do {
channel.write( message );
message = queue.get( session );
}
}
That would require a queue per session. So I don't see a difference to the
prior model. I thought you wanted a single queue for all session of an
IoProcessor.
No, only one queue is necessary, if we search for the message in the
queue for a specific session. Now, the problem would be to have the
rigth design for this queue (ie, it has to be searchable without having
to do a full scan).
Not sure if it's smart, though.
Does it sounds crazy ?
No, but I'm currently not seeing the difference, besides the fact that the
IoProcessor handles the queues. Maybe I'm misunderstanding your suggestion.
See upper. But I'm not sure it's the right idea.
* An additional cpu cost will be the increased synchronization
efforts inside the queue... There will be more threads, writing to the
same queue at the same time.
No, because the IoProcessor is using one single thread.
Ok, I'm not too deep into the IoProcessor, but I thought the writing requests
of different sessions (put to the queue) could be handled simultaneously, while
the IoProcessor itself is single-threaded (poll from the queue).
Each session is attached to an IoProcessor, so you may have messages
sent in parallel. But a session will always be processed by a single
IoProcessor.
Hmmmm, whatever the queues use, it's irrelevant. There is no reason
that
we don't use the same in the IoProcessor queue, as we have the exact
same number of elements in this queue than the number of all the
elements used in all the Session queues.
Maybe there is a little overhead for each queue, but I don't think that it is
big enough to justify a design for itself.
Yes, right.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
