[wx-discuss] wxSocket rewrite using Boost.Asio

[William H. Schultz]

On May 23, 2008, at 12:21 PM, Vadim Zeitlin wrote:

> On Fri, 23 May 2008 12:00:45 -0700 "William H. Schultz" <whschultz at cedrus.com 
> > wrote:
>
> WHS> I'm not convinced that the existing implementation necessarily
> WHS> preserves 90% of the API.
>
> Err, I don't really understand this. Anyhow, just to make clear what I
> meant: we need to be able to support all these weird wxSocket flags  
> (BLOCK
> &c).

I just mean that there's documented functionality that is close enough  
to useless that it could be argued that it's not available.

>
>
> WHS> Last I checked, IPv6 wasn't available.
>
> There is (untested by me personally) IPv6 support now but what does  
> this
> have to do with compatibility anyhow?

According to sckaddr.h, IPv6 isn't implemented.  sckaddr.cpp backs  
this up.  The following function should be enough evidence:


bool wxIPV6address::IsLocalHost() const
{
   return (Hostname() == wxT("localhost") || IPAddress() ==  
wxT("127.0.0.1"));
}


Therefore, no matter how it's written, it's impossible to break  
existing IPv6 code, since it doesn't exist, despite existing in the  
header file.



>
>
> WHS> A big problem  I've had is that "blocking" operations don't  
> block.
> WHS> They don't  return, but they don't block either--they chew up  
> 100% of
> WHS> the CPU.
>
> I'm pretty sure this is due to the incorrect use of wxSocket which was
> discussed to death on wx-users in the past. See the last message in  
> the
> "bringing wxSocket into shape" thread on wx-dev from Kevin Hock from
> 2007-12-22 for more explanations.

I don't recall off the top of my head the implementation that  
exhibited this problem, but I had been working on the code so long  
that I was well aware of the GUI issues, and I was aware of *why* it  
was chewing up 100% of a CPU, even running from a background thread.   
Ultimately, I had to poll using wxSocketBase::Peek() to see if data  
was available to be read, sleeping the thread manually.  All read and  
write operations block without giving time to the GUI, since they are  
running from a secondary thread.


>
>
> WHS> >> However I imagine that not everybody would be happy with  
> requiring
> WHS> >> Boost
> WHS>
> WHS> See:  http://www.boost.org/doc/libs/1_35_0/tools/bcp/bcp.html
>
> Requiring (relatively big) part of Boost is not very different from
> requiring all of it (speaking about the headers, anyhow, but it  
> seems that
> ASIO can be used without any other Boost libraries). Anyhow, if we  
> use ASIO
> for wxSocket it may make sense to also use other Boost classes.

bcp isn't as easy as the documentation makes it out to be...  I still  
haven't figured out how to just *build* the darn thing.

>
>
> WHS> wxWidgets 3.0 is supposed to be a major upgrade, right?   
> Wouldn't that
> WHS> make it a good time to drop support for old and broken  
> compilers and
> WHS> make major leaps forward in ease of programming?
>
> I'm actually ok with dropping support for VC6, you need to convince  
> Julian
> and all the others who continue to use it.
>
> But this still leaves the need to implement the baroque wxSocket API  
> on
> top of a rather different ASIO one. I'm sure that if you do it and  
> provide
> it in a usable form somewhere it will be very useful to a lot of  
> people
> whether or not it's included in wx itself. And sooner or later we  
> will drop
> VC6, of course, so we would be able to include it then. So I  
> definitely
> support the idea of doing it, I just can't promise that it is  
> integrated
> into wx 3.0 because it's not [only] my decision.

Not a problem.  While Asio and wxSocket are very different in  
appearance, they are both based on asynchronous functionality; I don't  
think it's going to be particularly tricky to make the existing API  
work.  I don't expect it to be easy, but I believe they are inherently  
compatible.

I've started today on figuring out how to organize the Asio classes  
within the existing wxSocket classes.  Asio is designed so that the  
difference between IPv4 and IPv6 is incredibly transparent...  so much  
so that wxIPaddress will probably no longer be an abstract class.   
IPv6 functionality needs to be seamless or the code will be dead  
within a couple of years.



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

-------------------------------
Hank Schultz
Cedrus Corporation
http://www.cedrus.com/
-------------- 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/20080527/d7530578/PGP.pgp