Re: Multithread safety

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

  • Re: Dr. Demento speaks up about his business
    ... My issue is portability. ... to download the show and play it on my iPod when I want to hear it, ... on your iPod whenever it's connected up. ...
    (rec.music.dementia)
  • Re: Multithread safety
    ... up to 64 simultaneous sockets present no problem in the ... BSD model since a single thread can handle them for I/O. ... At some point the number of threads in the client ... whereas portability might be important. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Multithread safety
    ... > That is of course true. ... At some point the number of threads in the client becomes ... whereas portability might be important. ... Sticking to BSD helps with the first way but this ...
    (microsoft.public.win32.programmer.networks)
  • Re: Interop with 32-bit and 64-bit
    ... Explicit casts are ... the client seems to be forced to explicitely ... int and long versions of the parameters. ... the "int" version when 64-bit portability is not an issue or ...
    (microsoft.public.dotnet.framework.interop)
  • Re: The Register interview Nigel Brown
    ... them to focus on the server side end of portability though, ... granually perhaps client side support when there is markets for that. ...
    (borland.public.delphi.non-technical)