"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:488f4c21$3@newsgroups.borland.com...
>
>
> I suggest you read up on how overlapped I/O and completion ports actually
> work:
> ...
Thanks for the useful references.
To qualify the point I made in my previous post about the relative
computational efficiency of non-blocking versus blocking socket I/O, I can
see that non-blocking socket I/O would be more efficient than a
well-programmed blocking socket I/O if the processor that performs the
background socket I/O is not one of the main processors used directly by the
OS to process threads, but a dedicated I/O interface processor. The same
also applies to overlapped I/O.
To revise the point I made about the suitability of the TTcpClient and
TTcpServer components for non-blocking socket I/O, I can see that although
the components don't support the more advanced Winsock 2 non-blocking and
overlapped socket I/O facilities (i.e. the API functions prefixed by WSA), I
would have thought that they can still be used for non-blocking socket I/O
if the select method is used to wait for asynchronous I/O completion.
>
> Not really. Repeatedly creating and tearing down threads has quite a bit
> of overhead to it, especially the shorter the time each thread runs for.
> If you are going to use such a model, then thread pooling would be a
> better choice.
>
I know that a thread pool can be used to avoid the overhead of repeated
thread object creation and destruction. But the point I made about the
impact of the duration of each thread session on overall efficiency still
holds, I would have thought, because the shorter the duration, the lower the
number of concurrently active threads.
>> With this code the thread created to handle the client connection
>> is released shortly after the OnAccept event handler is exited
>
> No, it is not. Look at the TTcpServer source code more carefully. The
> thread calls the OnAccept event in a loop, one firing per client
> connection. When the OnAccept handler exits, the thread loops back and
> processes the next client connection, or goes to sleep if there is no
> pending client.
>
I was aware that TTcpServer uses a thread pool for client socket threads. By
'released', I didn't mean destroyed, but released from active service and
returned to the pool of inactive threads.
I have read in accounts of socket facilities provided by other languages
about the importance of calling the 'flush' function between a send and recv
call to ensure that socket I/O operation is completed and all data in the
socket's outgoing data stream buffer is sent down the line. I haven't found
a function by this name in the WinSock API, or in the Delphi components.
Does this mean that the send and recv Windows API functions automatically
take care of flushing the buffer?
Regards,
EM
