Re: Multithread safety

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I hope you are not suggesting I have to write my entire network
layer for each new platform :). I only need to abstract the socket
layer. All the code to download a file will be shared among all
platforms.

Also, 64 is very low for a server, but a client hardly ever needs
more than ten simultaneous connections, so the limitation is ok.
Furthermore, a server has to scale, so it would necessarily delve
into the more efficient APIs like IOCP anyway.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
news:ess7MHW5FHA.692@xxxxxxxxxxxxxxxxxxxxxxx
> Alexander Nickolov wrote:
>> I agree on most of your points. However, you misinterpreted
>> me somewhat on the portability. The use of the BSD API model
>> is important, e.g. non-blocking sockets with select. If you switch
>> to any other WinSock model (WSAEventSelect, WSAAsyncSelect,
>> overlapped, or IOCP), your design won't be portable - it's harder
>> to abstract it when you have so varying threading model requirements.
>
> Why? Threading can be hidden behind an abstraction. Let's take the most
> trivial example. When you want to download a policy file from a server all
> you want to use is something like this
>
> void InitDownloadEngine();
> DownloadHandle StartDownload(string download_info);
> File WaitForResult(DownloadHandle d, time_t timeout);
> void CloseDownloadEngine();
>
> With opaque definition of DownloadHandle and portable File this API can be
> portably used everywhere. What the download engine does inside doesn't
> really matter to the client code.
>
> Of course initially writing the engine for a new platform will be slower
> but I beleive that in long run this will save time compared to #ifdef
> approach.
>
>> Besides, up to 64 simultaneous sockets present no problem in the
>> BSD model since a single thread can handle them for I/O. You can
>> have more in Unix, but that doesn't port to Windows.
>
> True. The problem is that 64 is too low a number. It is certainly within
> reach of a modern client but it is high enough to pose no problem during
> prototyping and/or initial project release. Which means that one is likely
> to discover that it is not enough *late* in the project ;-) Had it been
> 256 or even better 1024 I probably wouldn't mind this limitation on the
> client side.
>
> --
> Eugene
> http://www.gershnik.com
>
>


.

Relevant Pages