Remy Maucherat wrote:
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.
true. lets see how it pans out in actual code, that might change our
perspective.
I was toying around with an alternative idea too, disallow any read or
write all together unless it is done on a worker thread. gives us
complete control, easier to implement.
public void CometEvent.notify(int operations);
operations = READ | WRITE | NOW;
READ - this is what we do now under the covers, this would give the user
the control, basically means, notify me when there is data to read
WRITE - notify me when I can write data
NOW - send me a worker thread my way, so that I can safely initiate a
blocking or non blocking read or write.
the event WRITE_COMPLETE is still present, after a non blocking write
succeeds.
all the other stuff we talked about, still happens under the covers.
This alternate method would just avoid any need for synchronization for
the servlet developer,
as we can control that underneath.
This would make for a cleaner, more thread safe API (or at least easier
to code it thread safe for the servlet developer).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
