Christopher Kohlhoff wrote:
Hi Rene,
--- Rene Rivera <grafik.list@redshift-software.com> wrote: <snip>
My original contention is a compatibility concern. I want to be able to write a *single* program that for compatibility can run on Linux 2.4 and above. In such a situation I need to query the OS to find out the optimal (from my point of view not Asios' POV) method and instantiate/use it. Hence I am using more information than is available when Asio makes its optimization choice.
But if your use case is as you described before, where you only have one or a small number of sockets, then why not just compile for a Linux 2.4 target only?
Because this is a concern for everyone. I might be the only person currently asking for this, but I won't be the last. I am raising these issues for the general benefit of the Boost review. Someone has to think about how the library addresses the full spectrum of needs, even if it wasn't originally designed for it. The best designed libraries can accommodate unknown uses. But if your position is that since it doesn't allow for a certain, to my POV, reasonable modularity standard to just "hack" around it, I'd have to say that my vote went from "no but I would consider changing it". To a: "vehement no". I don't want to see libraries in Boost that fail some basic abstraction uses. But to make the selection of which method, epoll, select, etc., to use more salient to you personally, I have a simple question for you if Asio is accepted into Boost: How do you expect to write tests for your library that cover *all* the various methods supported in one platform? PS. I know I'm probably getting on your nerves by now. But that's what reviews are like ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org