tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Comet changes
Date Wed, 09 May 2007 14:33:56 GMT
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 

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 

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:
For additional commands, e-mail:

View raw message