[wx-discuss] wxSocket rewrite using Boost.Asio

Fri May 23 12:00:45 PDT 2008

On May 23, 2008, at 9:01 AM, Kevin Ollivier wrote:

> Hi Vadim and all,
>
> On May 23, 2008, at 5:30 AM, Vadim Zeitlin wrote:
>
>> On Thu, 22 May 2008 18:06:49 -0700 "William H. Schultz" <whschultz at cedrus.com 
>> > wrote:
>>
>> WHS> I'm about to undertake a major rewrite of my socket code, and  
>> I'm
>> WHS> leaning toward reimplementing wxSocket to use Boost.Asio (vs.
>> WHS> replacing wxSocket in our code with Boost.Asio).
>>
>> Replacing wxSocket with a 3rd party library is definitely very, very
>> tempting, I'm sure that ASIO is much better than the existing code.  
>> The
>> problem is whether we're going to be able to preserve the existing  
>> API
>> (even if not 100%, but at least 90%).

I'm not convinced that the existing implementation necessarily  
preserves 90% of the API.  Last I checked, IPv6 wasn't available.  Of  
course, my memory could be failing me on this detail.  A big problem  
I've had is that "blocking" operations don't *block*.  They don't  
return, but they don't block either--they chew up 100% of the CPU.

Anyway, I'm looking through the existing documented API to see if  
there's anything that seems like it may not be applicable (or  
implementable).  I'm still making sense of the Asio API, but I'm only  
seeing one sticking point:

http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/design/threads.html
http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/io_service.html

My take on this is that an implementation using Asio would require one  
of two things:  1)  call io_service::poll in the application's idle  
time, or 2) spawn a separate thread to call io_service::run.  I would  
prefer the second approach, but I'm aware that this potentially  
requires compiling wxWidgets with wxThread support (unless it's  
implemented using boost's thread functionality); therefore, the first  
approach would probably be the default.  I don't feel I'll know what's  
truly best until I start trying things, though.

One key piece of functionality that I'm looking to implement that  
isn't offered by either library is the ability to spawn a separate  
process for multiple connections to a server--the benefit being that a  
crash only affects one client.  I'd appreciate any input on whether  
this is a good or bad idea.  I know apache takes this approach (or at  
least a similar approach).

>>
>>
>> However I imagine that not everybody would be happy with requiring  
>> Boost

See:  http://www.boost.org/doc/libs/1_35_0/tools/bcp/bcp.html

>>
>> to build wx and, worse, ASIO doesn't seem to support VC6 which we're
>> apparently not ready to abandon yet. So while I personally would  
>> like to do
>> what you propose provided backwards compatibility could be more or  
>> less
>> preserved, I'm afraid VC6 is going to be the sticking point :-(
>
> I'm beginning to think the slogan for wx should be "let's program  
> like it's 1999!" ;-) The rest of the world is moving on (in fact,  
> VC6 hasn't been available for purchase for half a decade), and if wx  
> doesn't move on too, users will leave it behind just like they did  
> VC6.
>
> For users who refuse to change and update, there are always the  
> existing and old versions of wx. And that's how any development  
> process should work, because the toolkit today should focus on the  
> needs of the users today (and, more importantly, tomorrow), not  
> focus on keeping apps written 10 years ago from breaking. If a  
> particular app developer doesn't want to change and update their  
> code, or can't afford to over the course of several years, they  
> don't have to change their wx version - the old one will run as it  
> always did.

I agree.  On the Mac, wxWidgets has already dropped support for 10.2.x  
and older (or is it anything older than 10.3.9?).  We're (Cedrus) on  
the verge of dropping support even for 10.3.9 (released April of  
2005).  On Windows, however, wxWidgets still supports Visual C++ 6,  
released in 1998.  According to the wxWidgets website, VC5 is still  
supported ( http://www.wxwidgets.org/about/feature2.htm ), as is  
Windows 95.  At Cedrus, we recently switched to Visual Studio 2005  
because the VS7.1 compiler was failing to compile valid C++ code.  The  
longer wxWidgets supports archaic platforms with new code, the harder  
it's going to be to support new *standards* (see C++0x http://en.wikipedia.org/wiki/C%2B%2B0x 
  ).

There are various areas of our software where we've not used  
wxWidgets, as the implementation was too backwards to be useful,  
wxMediaCtrl and wxSound being two major examples.  On the Mac,  
wxMutex, wxBitmap, and wxDC are a few more examples (note that I'm  
referring to the wxDC of two years ago here and comparing wxBitmap to  
what QuickTime has to offer).  We've already left wxWidgets behind  
with all of these classes.  wxSocket is close to being added to the  
list.

>
>
> +1 to Stefan's ideas.
>
> Regards,
>
> Kevin
>
>>
>> Regards,
>> VZ
>>

wxWidgets 3.0 is supposed to be a major upgrade, right?  Wouldn't that  
make it a good time to drop support for old and broken compilers and  
make major leaps forward in ease of programming?

-------------------------------
Hank Schultz
Cedrus Corporation
http://www.cedrus.com/

>> _______________________________________________
>> wx-discuss mailing list
>> wx-discuss at lists.wxwidgets.org
>> http://lists.wxwidgets.org/mailman/listinfo/wx-discuss
>
> _______________________________________________
> wx-discuss mailing list
> wx-discuss at lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wx-discuss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.wxwidgets.org/pipermail/wx-discuss/attachments/20080523/9171990d/PGP.pgp