Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> 1. CometEvent.notify is a servlet calling container method,not a
>> callback from the container
>
> The servlet calls the "notify" method, right ?
>
>> 2. Introduce a new EventType -> NOTIFY
>> 3. Keep the sub event type -> WRITE_COMPLETE, instead of having to
>> busy poll CometEvent.canWrite()
>
> I'd like to know where this "busy poll" for CometEvent.canWrite()
> comes from ;) That flag would be used like available is, such as:
we're thinking along the same lines.
I was more thinking
if ( event.isWriteable() ) {
os.write(data);
} else {
event.register(WRITE);
}
so instead of WRITE_COMPLETE event, your idea of letting the servlet
know when it can receive more data NOTIFY/WRITE, is essentially the same
message.
so I'm happy to do it this way.
"while" or "if" depends on the app of course.
The "busy poll" thoughts came up because I thought you were against any
event notification.
>
> while (event.canWrite()) { {
> os.write(randomData);
> }
> _notify(WRITE);
>
> I am not ok to have to wait for an event following each write, since
> it has a huge cost (the canWrite flag is there to be able to do it
> only when it is needed).
agreed.
>
>> 4. Introduce CometEvent.setBlocking(true|false)
>> 5. CometEvent.notify(NOW) to spawn an instant thread, for example,
>> changing blocking -> non blocking and the other way around should be
>> done on a Tomcat worker thread, too many race condition can occur
>> from doing it async with a background thread. Also useful for
>> blocking writes when that is desired
>
> Changing blocking mode in the middle is a bit extreme, I think.
it is. For rev 1, lets only allow it during the "BEGIN" event, and throw
an exception if it is done anytime outside of that.
>
>> and third scenario, useful when you want to end the request, but
>> don't want to wait for an IO event or a timeout.(event.close() ->
>> event.notify(NOW) or the other way around)
>> EventType-> NOTIFY SubEventType->NOW
>
> "notify" is not possible as a method name, any ideas ? I am ok with
> using the proposed notify subtypes.
I suggest these methods
event.configure - instead of setBlocking - as I'd like to set a flag to
not register with poller as well, so we can use int options
event.register - instead of notify
event.isWriteable - instead of canWrite
>
> Overall, I would be happier to not be doing non blocking IO. There
> will be a lot of ifs in the code, and it will be pretty complex to test.
welcome to my world :) NIO implementing non blocking for a blocking API.
I'll have the API changes in in another 2 hours
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
|