On 05/24/2013 01:14 AM, Greg Wilkins wrote:
> I don't see how this choice can be made for blocking? You signal an
> async write by calling isReady() before calling write. So a blocking
> write is chosen by not calling isReady, but then you can't know if the
> previous write is complete and can't avoid the concurrent write.
> Fragile code will result that will mostly work until confronted by a
> slow client.
>
Ok, I think I see what you mean.
The granularity of the autoblocking is not per individual write. At
most, you could allow a blocking write followed by an async one, but
writing after an async write is only allowed if it did really complete
(so if you try not using isReady because you would like to block, then
it is not allowed). So once you do an async write, you wouldn't be able
to do a blocking write until the next write event (since isReady was
used for the first async write). In an impl, isReady would simply switch
a nonBlock flag that would stay until the next event where it would be
reset to false.
Rémy