On 21 May 2013 18:07, Rémy Maucherat <rmaucher_at_redhat.com> wrote:
> On 05/21/2013 01:42 AM, Greg Wilkins wrote:
>
>
> I come to the conclusion that autoblocking is over complex and provides a
> semantic that we don't want to provide.
>
> The simplified state machine that results is:
>
> ACTION OPEN ASYNC READY PENDING
> UNREADY
>
> -------------------------------------------------------------------------------------
> setWriteListener() READY->owp ise ise ise
> ise
> write() OPEN ise PENDING wpe
> wpe
> isReady() ise READY:true READY:true UNREADY:false
> UNREADY:false
> write completed - - - ASYNC
> READY->owp
>
> Yes, it is simpler. But then not doing it makes some (bad, IMO) use
> cases much harder.
>
> About concurrent writes, it is never possible, there is no queue needed.
> If the user uses async writes, he knows it, and has to wait for owp to
> continue writing. Anything else is illegal. In blocking mode, the container
> thread blocks, it is then up to the user to not do any concurrent write
> since it is illegal too (as with a regular servlet). Overall, it's similar
> to NIO2 on sockets for the general behavior: any write can be blocking or
> async, but concurrency is never allowed.
>
From your response, I think I don't understand what autoblocking is?
I'm with you when you say: "If the user uses async writes, he knows it, and
has to wait for owp to continue writing" - exactly, so they must call
isReady() in order to get a OWP callback.
I'm also with you when you say: "In blocking mode, the container thread
blocks, it is then up to the user to not do any concurrent write since it
is illegal too (as with a regular servlet)", as we obviously want blocking
mode to be exactly what we have now.
But I thought the idea of autoblocking was to provide a way to switch from
asynchronous mode back to blocking mode, and the problem is that I don't
see how that is possible to do AND keep the above to summaries true. If we
are in asynchronous mode and wish to automagically return to blocking mode
- then the suggestion has been made that this can be done simply by not
calling isReady() after the last asynchronous write. But if we do that,
then we have to allow concurrent writes, because the write made without
calling isReady might take place before the previous write is complete.
The only way to know if the previous write is complete is to call isReady
and that make that write asynchronous!
So if you think there is a way to switch back from async to blocking IO,
I'd really like to see the detail of that. Currently I can't see how it
can be done without allowing concurrency and I don't want to allow
concurrent support.
cheers
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.