Ossama Othman wrote:
>
> Hi,
>
> On Wed, May 15, 2002 at 08:12:29PM +0530, K S Sreeram wrote:
> > > When relying on WRITE events using the ACE_WFMO_Reactor, you must
> > > therefore continue to write until the connection closes or the socket
> > > becomes flow controlled, i.e., a send fails with EWOULDBLOCK.
> >
> > if ( write() == EWOULDBLOCK ) then {
> > ...
> > . ...
> > ...
> > wmfo_reactor->handle_events()
> > }
> >
> > what happens when the socket transitions from flow-controlled to writeable
> > after the call to write but before the call to handle_events()? If WFMO, is
> > not going to notify the caller about the transition, then using WFMO_Reactor
> > for socket write notification would not be reliable, and hence should never
> > be used...
>
> The event hasn't been reported yet so presumably the WFMO reactor will
> still report the event. If not, then Windows'
> WaitForMultipleObjects() call bites. ;-)

Think of each waitable socket as having an internal flag. It is set
when EWOULDBLOCK is returned by a write, and reset when
WaitForMultipleObjects returns that the sockeet is writable. If your
application code doesn't cause the flag to toggle back and forth by
properly interleaving write() calls that return EWOULDBLOCK with
WaitForMultipleObjects() calls, then your code is broken.

--
Jon Biggar
Floorboard Software
jon@...
jon@...