On 05/23/2013 12:36 AM, Greg Wilkins wrote:
>
>
>
> On 21 May 2013 18:07, Rémy Maucherat <rmaucher_at_redhat.com
> <mailto: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.
Once a write is in progress, it cannot change retroactively between
blocking and async (and this is the issue with websockets which allows
blocking the container thread after making an async write). I don't see
the issue since I mentioned this was like NIO2, so:
- No concurrent writes (it a write is pending, there is an exception).
- A write can be async or blocking and the choice is made when calling
the write.
OTOH, since autoblocking (or my take on it) doesn't solve websockets,
adding it is not required.
Rémy