On Tue, 12 Apr 2005 07:41:34 -0700 (PDT), Don G <dongryphon@yahoo.com> wrote: []
I am curious to know what folks think about this approach.
Hi Don, I skimmed through you stuff. It confused me a lot. What kind of applications is that targeted for? For a heavy duty high performance server you don't want to use it, because the abstractions you provide do have a price, and I'm not sure about the quality of implementation. What you need when doing such a server is to stick close to the metal, not paying for (I'm pretty sure you know that) useless context switches, lock contention, memory allocations and data copies. One really don't care about Linux/Windoze portability for this kind of servers just because Windoze is not an option for it's poor network performance and inherent security breaches. For a simple portable application one would probably stick to BSD nonblocking sockets + select() or blocking sockets + threads. The resulting code size will probably close to that of the code using your stuff, but code transparency and complexity will be in favor of the former for sure. Aside from this, I'm rather skeptical about the library you are working on guys. IMO, the root of all problems and complexity is its intended portability. The target platforms' APIs are too different to make implementation efficient and usable for any kind serious network application. If M$ does not care about its network APIs portability, why would anyone else care about it? -- Maxim Yegorushkin