🚀 go-pugleaf

"Hans Galema" <notused@notused.nl> wrote in message
news:41f942e7$1@newsgroups.borland.com...

> Of course that was a logical conclusion. Vinicius was speaking
> of events. There are only onread events in non-blocking mode.

In TServerSocket, if you do not provide a custom TServerClientThread
descendant class to handle connections, then OnClientRead is still triggered
even in blocking mode.

> It has all to do with it. If it is a blocking client it will will try to
read
> as soon as it expects data from the server. Here just after sending
> a command.

That does not mean that a non-blocking socket can't also read immediately
after writting, because it can.  You are getting too hung up on the presense
of event handlers and not focusing on what the socket can actually do in
either mode.  You can program a non-blocking socket in exactly the same
manner as a blocking socket, even to go as far as getting rid of the event
handlers.  All you have to do is take into account that operations may block
occasionally, but that is easily handled by simply checking for
WSAEWOULDBLOCK when non-blocking operations report errors.

> When it was non-blocking it would do nothing after sendig a command.

Yes, it can.  I've even posted examples of exactly that in the past.

> Well I do not know what Vinicius server is up to so that's
> why I asked. Apparently you know already. Strange.

I know exactly what Vinicius is asking for, because he stated as much in his
original message.  It has nothing to do with what the server is doing.  He
simply wanted to implement an OnExecute approach to client-side reading.  To
which that question has already been answered.

> Indeed the actual implementation depends on the protocol. But
> also on the blockingmode.

No, it does not.  Blocking vs. non-blocking does not change how the data can
be sent/read.  Both modes can be programmed in exactly the same manner.  The
events that can be triggered during non-blocking mode are NOT a requirement.


Gambit