Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
So it uses a poller automatically, and the WRITE event would be sent
when the socket is signaled by the poller, then. This is very similar.
The only problem is that it could cause sync issues, since the servlet
doesn't know for sure when the write poller is used.
this is much lower than the servlet and comet events. when doing
socketchannel.write, no poller, or selectors are involved. If there
simply isn't space on the buffer, it returns 0.
At this point, the InternalNioOutputBuffer would register the socket,
and the servlet thread would return.
When the poller detects "write available on socket", it wakes up,
internally it would try to write the remaining data from bbuf.
when all data from bbuf is written, the worker thread then proceeds to
signal the servlet with a NOTIFY/WRITE_COMPLETE
so all the actual non blocking writing is hidden from the user/servlet.
and no sync issues should arise since we will follow your suggestion and
throw an exception.
Yes, I perfectly understand that, and it mostly works. However, there's
maybe a time gap for trouble:
- the write returns 0
- the "available" flag for write goes to false
- the socket is put in the write poller
- the stack that lead to the write resolves, and the code returns to the
servlet; the servlet is supposed to look at the "available" flag, see
that it false, and stop writing
- meanwhile, the socket lands in the poller (quickly or not), and could
exit the poller quickly too, which triggers the flush of the leftover
bytes and the WRITE_COMPLETE event
So there could be a race between the servlet checking the "available"
flag and the flush, so the flush could be done at the same time as
another write by the servlet. This is very unlikely (and maybe it cannot
happen), but this is why I preferred using a method that the servlet
would be calling after checking the "available" flag.
There is a timeout for write in blocking mode, but not in non blocking
mode. The timeout is tracked by the poller structure, but mostly
concerns read events, so it is possible for a socket to timeout when
there are no read events, even if there is write activity on the socket.
yes, with NIO we update this poller structure even during async writes,
so if there is write activity on the socket, the socket wont timeout.
Ok, I had understood correctly then. I will not be doing that in APR.
This would cost many syncs and other operations, which is not acceptable
just for supporting this "feature".
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
