Re: Multithread safety

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.
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.

--
=====================================
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:%238H$PhP5FHA.2560@xxxxxxxxxxxxxxxxxxxxxxx
> Alexander Nickolov wrote:
>> That is of course true. Scalability at least is unimportant for
>> clients,
>
> I used to think so too but now I am not so sure. Once upon a time a client
> meant a desktop application that occasionally grabbed some info from
> server. Now I find "clients" simultaneously opening few dozen connections
> for various purposes. At some point the number of threads in the client
> becomes too big.
>
>> however, whereas portability might be important.
>> While I agree the code won't be 100% platform independent,
>> it's much easier to port code based on puire BSD APIs than
>> one based on the extended WinSock functions and concepts.
>
> This is true but up to a point. There are two kinds of porting: tweaking
> existing code with #ifdefs or providing a new implementation of a
> "networking layer". Sticking to BSD helps with the first way but this
> approach is flawed to begin with. It is fast in the beginning but very
> hard to maintain. It also forces you to the lowest common denominator
> everywhere (not just with sockets). Using the second way you are not
> constarained to BSD. In my experience I found it easier to abstract the
> "networking layer" and re-wrtie it for each platform group. But then I
> only had to support Windows-Unix portability.
>
>> Then again, portability is not important for a lot of folks anyway...
>
> Yeah. Especially to the "client" folks.
>
>
> --
> Eugene
> http://www.gershnik.com
>
>
>


.

Relevant Pages

  • 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)
  • Off: vpnc haxx
    ... This won't be exactly bsd specific topic but I saw others posted about vpnc so I think some of you have a clue about cisco devices and ios;) ... So I have a cisco vpn router somewhere. ... As I saw this is impossible in windows and in linux or in bsd I can use a vpnc connect script that's true to modify the tunnel parameters but here is a little problem, if I modify it then everything will be unaccessible in the vpn, like the router does not accept my traffic from that point. ... Ok so if I have 2 client on this subnet they can reach each other via encrypted tunnel. ...
    (freebsd-net)
  • Off: vpnc haxx
    ... vpnc so I think some of you have a clue about cisco devices and ios;) ... So I have a cisco vpn router somewhere (where I don't have admin ... As I saw this is impossible in windows and in linux or in bsd I can use ... Ok so if I have 2 client on this subnet they can reach each other via ...
    (freebsd-net)
  • Re: Cursor libraries
    ... What's wrong with advocating portable programming in c.l.c? ... >BSD getch doesn't do a refresh, doesn't provide for returning function keys. ... and portability. ... >> window can be deleted. ...
    (comp.lang.c)
  • Re: Someone explain (Mc)Clim to me as if I were 5 years old
    ... stream, true callbacks, access to the many Tk/Tcl libs, and terrific ... portability (of more than just the native look/feel GUI -- sockets, ...
    (comp.lang.lisp)