[asio-users] Can't catch Boost.Asio exceptions inside coroutines

Discussion:

Sergey Shpikin

2016-10-26 15:48:55 UTC

I have this little example of Boost.Asio code:
http://codepad.org/tuQedXI7 It works as expected on Linux producing
1
2
Caught Host not found (authoritative)

but on Windows it crashes with:
1
2
terminate called after throwing an instance of 'boost::system::system_error'
what(): Unknown error

Tested on Windows Server 2008, Windows 7 and Wine, everything is the
same. I'm compiling on Linux for Windows with MXE ( http://mxe.cc/ )
on GCC 4.9.4, Boost version is 1.60.0. I'm really stuck at this point
as nothing in Google looks a valid solution for the case and I already
have a working application on Linux but it crashes on any network
error on Windows.

On Windows coroutines prevent any exceptions from being caught when
the program is compiled with -O1/2/3 but they're caught with -O0 or
-Os (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54267 — this is
about GCC on FreeBSD but the same seemingly applies to MinGW).
However, boost's own exceptions, like the aforementioned
boost::system::system_error, still can't be caught.

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List yo

Allen

2016-10-26 17:19:42 UTC

Permalink

This looks like a compiler/toolchain issue. Give it a try with
MinGW-w64 4.8.5 Posix threads SEH which can be found at

http://downloads.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.5/threads-posix/seh/x86_64-4.8.5-release-posix-seh-rt_v4-rev0.7z

And to get a complete toolchain, combine that with the MSYS binaries
included with

http://downloads.sourceforge.net/project/mingw/Installer/mingw-get-setup.exe

If you install to the default directories, you need to put
C:\mingw64\bin and C:\MinGW\msys\1.0\bin at the front of your PATH
when building.

Try building and linking to boost both as a DLL and a static library.
Note when building boost, after running bootstrap.bat, you need to
edit project-config.jam and change "using msvc" to "using gcc" before
running b2.exe.

Hope this helps.

Post by Sergey Shpikin
http://codepad.org/tuQedXI7 It works as expected on Linux producing
1
2
Caught Host not found (authoritative)
1
2
terminate called after throwing an instance of 'boost::system::system_error'
what(): Unknown error
Tested on Windows Server 2008, Windows 7 and Wine, everything is the
same. I'm compiling on Linux for Windows with MXE ( http://mxe.cc/ )
on GCC 4.9.4, Boost version is 1.60.0. I'm really stuck at this point
as nothing in Google looks a valid solution for the case and I already
have a working application on Linux but it crashes on any network
error on Windows.
On Windows coroutines prevent any exceptions from being caught when
the program is compiled with -O1/2/3 but they're caught with -O0 or
-Os (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54267 — this is
about GCC on FreeBSD but the same seemingly applies to MinGW).
However, boost's own exceptions, like the aforementioned
boost::system::system_error, still can't be caught.
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/Wh

Allen

2016-10-26 17:25:09 UTC

Permalink

P.S., the link I gave you is for MinGW targeting Window x64. There is
also a version targeting Window x86 if that is what you want.

Post by Allen
This looks like a compiler/toolchain issue. Give it a try with
MinGW-w64 4.8.5 Posix threads SEH which can be found at
http://downloads.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.5/threads-posix/seh/x86_64-4.8.5-release-posix-seh-rt_v4-rev0.7z
And to get a complete toolchain, combine that with the MSYS binaries
included with
http://downloads.sourceforge.net/project/mingw/Installer/mingw-get-setup.exe
If you install to the default directories, you need to put
C:\mingw64\bin and C:\MinGW\msys\1.0\bin at the front of your PATH
when building.
Try building and linking to boost both as a DLL and a static library.
Note when building boost, after running bootstrap.bat, you need to
edit project-config.jam and change "using msvc" to "using gcc" before
running b2.exe.
Hope this helps.

Igor R

2016-10-26 19:34:52 UTC

Permalink

Shouldn't the exception handler be around iosrv.run() ?

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Sergey Shpikin

2016-10-26 20:38:35 UTC

Permalink

No, it works perfectly fine on Linux and catches exceptions where I
need them. I tried to catch on iosrv.run() and it results in an access
violation instead of std::terminate. I'll try Allen's suggestion soon,
it also looks to me like a compiler issue but I'm used to MXE and not
sure I'll be able to compile everything I need by hand. MXE includes
lots of patches and settings to make everything to "just work" (well,
not always probably). Do you have any ideas why exceptions could go
through the handlers on Windows specifically?

Post by Igor R

Shouldn't the exception handler be around iosrv.run() ?
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Andrey Goryachev

2016-10-26 22:53:42 UTC

Permalink

Have you tried to reproduce the bug without asio, just with
throw-catch in a boost coroutine? If it's a bug in Boost.Coroutine,
you probably should file it to boost's bug tracker or ask in boost's
mailing list.

Post by Sergey Shpikin
No, it works perfectly fine on Linux and catches exceptions where I
need them. I tried to catch on iosrv.run() and it results in an access
violation instead of std::terminate. I'll try Allen's suggestion soon,
it also looks to me like a compiler issue but I'm used to MXE and not
sure I'll be able to compile everything I need by hand. MXE includes
lots of patches and settings to make everything to "just work" (well,
not always probably). Do you have any ideas why exceptions could go
through the handlers on Windows specifically?

Post by Igor R

Shouldn't the exception handler be around iosrv.run() ?
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Sergey Shpikin

2016-10-27 04:51:25 UTC

Permalink

std::runtime_error is caught fine, only own asio errors like connection or
resolve errors aren't. That's why I suspect asio and not just coroutines.

Post by Andrey Goryachev
Have you tried to reproduce the bug without asio, just with
throw-catch in a boost coroutine? If it's a bug in Boost.Coroutine,
you probably should file it to boost's bug tracker or ask in boost's
mailing list.

Post by Igor R

Post by Sergey Shpikin
http://codepad.org/tuQedXI7 It works as expected on Linux producing
1
2
Caught Host not found (authoritative)
1
2
terminate called after throwing an instance of

'boost::system::system_error'

Post by Sergey Shpikin

Post by Igor R

Post by Sergey Shpikin
what(): Unknown error

Shouldn't the exception handler be around iosrv.run() ?
------------------------------------------------------------

------------------

Post by Sergey Shpikin

Post by Igor R
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------

------------------

Post by Sergey Shpikin
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------
------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Allen

2016-10-26 23:13:37 UTC

Permalink

Are you linking to pre-built boost DLL's provided by MXE? If so, the
DLL is probably not seeing the exception handler created by your
program, probably because the compiler is not creating the exception
handler in the way expected by the DLL. If that is the case, there
might be some compiler command line options that would fix it, or
possibly the compiler was not built correctly to support exceptions
coming from DLL's. Linking to a static boost library instead of a DLL
might fix it though either way. You might not have to change toolsets
if you simply download and compile boost static libraries yourself.
It's not that hard:

cd <boost source code directory>
bootstrap.bat
possibly edit project-config.jam and change "using msvc" to "using gcc"
b2 --layout=system variant=release threading=multi link=static
runtime-link=static --without-python

The output should be "The Boost C++ Libraries were successfully
built!" and the link libraries will be in <boost directory>\stage\lib

Post by Igor R

Shouldn't the exception handler be around iosrv.run() ?
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Allen

2016-10-27 04:59:30 UTC

Permalink

ok, I focused on exceptions from DLL's because unix tools have
historically had problems in that area, But the same thing could apply
to a static library--the static library could have been compiled to
look for exception handlers in a different format than the compiler is
creating for your application. I would still suggest building your
own boost static libraries as a first step.

MXE always links everything statically, that's one is the reasons I'm using
it.

Post by Allen
Are you linking to pre-built boost DLL's provided by MXE? If so, the
DLL is probably not seeing the exception handler created by your
program, probably because the compiler is not creating the exception
handler in the way expected by the DLL. If that is the case, there
might be some compiler command line options that would fix it, or
possibly the compiler was not built correctly to support exceptions
coming from DLL's. Linking to a static boost library instead of a DLL
might fix it though either way. You might not have to change toolsets
if you simply download and compile boost static libraries yourself.
cd <boost source code directory>
bootstrap.bat
possibly edit project-config.jam and change "using msvc" to "using gcc"
b2 --layout=system variant=release threading=multi link=static
runtime-link=static --without-python
The output should be "The Boost C++ Libraries were successfully
built!" and the link libraries will be in <boost directory>\stage\lib

Post by Igor R

Shouldn't the exception handler be around iosrv.run() ?
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Allen

2016-10-27 05:15:35 UTC

Permalink

ok, I suggest trying a different compiler/toolchain. The MinGW-w64
project provides toolchains targeting Win32 and Win64, with various
threading and exception handling models. I myself use version 4.8.5
with Posix threads and SEH exception handling targeting Win64, along
with the MSYS tools, which I linked to in my first reply. But you can
pick any of many to try.

Win64: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/

Win32: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/

That's all the help I can offer, and this will be my last reply--I
have my own work I need to get done.

MXE is just a modular makefile, it builds everything from source with
pre-specified flags, including gcc and boost. So I'm compiling my own
program with the same compiler that's used to compile boost. There's nothing
binary in MXE, at all.

Post by Allen
ok, I focused on exceptions from DLL's because unix tools have
historically had problems in that area, But the same thing could apply
to a static library--the static library could have been compiled to
look for exception handlers in a different format than the compiler is
creating for your application. I would still suggest building your
own boost static libraries as a first step.

MXE always links everything statically, that's one is the reasons I'm using
it.

Post by Igor R

Shouldn't the exception handler be around iosrv.run() ?
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

niXman

2016-10-27 05:40:54 UTC

Permalink

Works as expected for me using i686-6.2.0-release-posix-dwarf-rev1[1] &
boost-1.62.

[1]
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/6.2.0/threads-posix/dwarf/i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z
--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http:

Sergey Shpikin

2016-10-27 06:01:55 UTC

Permalink

Good to know that at least one configuration is working, thank you for
testing! That MinGW build is for Windows, unfortunately, and I'd like
to compile on Linux for Windows.

Post by niXman

Works as expected for me using i686-6.2.0-release-posix-dwarf-rev1[1] &
boost-1.62.
[1]
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/6.2.0/threads-posix/dwarf/i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z
--
Regards, niXman
___________________________________________________
http://sourceforge.net/projects/mingw-w64/
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Sergey Shpikin

2016-10-27 11:49:17 UTC

Permalink

Solved this with #define BOOST_ASIO_DISABLE_THREADS

I've compiled gdb for Windows and started the test program with it. On
Windows there were 3 threads and on Linux only 1 so I tried to
recompile Boost with threadapi=pthread (just in case there's an issue
with threading) but in the end it didn't compile libboost_thread*.a
and I gave up. After a while I realized that the exception could be
thrown in one thread and caught (unsuccessfully) in the main thread or
some other so I googled for how to disable ASIO threads and that
really helped.

MXE uses threadapi=win32 and threading=multi, probably switching the
latter to single and recompiling boost would help as well but it seems
not to be an easy task with MXE. As I found out there's little to no
info about that threading option (found only this answer:
http://stackoverflow.com/questions/20859761/what-exactly-does-threading-multi-do-when-compiling-boost
and it doesn't mention any issues with exceptions) so I don't know if
it breaks something else if I change it and what exactly changes in
multithreaded boost. For instance, how to deal with exceptions in my
case. Maybe that's a flaw in ASIO itself but I'd refrain from drawing
any conclusions.

Honestly, I don't like it when an abstraction leaks this badly and
instead of added "behind the scenes" efficiency I have to deal with
uncaught exceptions that are clearly have to be caught in this
simplest piece of code.

Post by Sergey Shpikin
Good to know that at least one configuration is working, thank you for
testing! That MinGW build is for Windows, unfortunately, and I'd like
to compile on Linux for Windows.

Post by niXman

Works as expected for me using i686-6.2.0-release-posix-dwarf-rev1[1] &
boost-1.62.
[1]
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/6.2.0/threads-posix/dwarf/i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z
--
Regards, niXman
___________________________________________________
http://sourceforge.net/projects/mingw-w64/
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

Sergey Shpikin

2016-10-27 14:34:06 UTC

Permalink

Nope, not solved. If I disable threads I just get a thread exception
with .what() saying "Unknown error". I can't find any "model" build of
boost for MinGW, the official one is for Visual Studio and I still
can't build it without implicit multithreading. I'm not even sure it's
the culprit.

Post by Sergey Shpikin
Solved this with #define BOOST_ASIO_DISABLE_THREADS
I've compiled gdb for Windows and started the test program with it. On
Windows there were 3 threads and on Linux only 1 so I tried to
recompile Boost with threadapi=pthread (just in case there's an issue
with threading) but in the end it didn't compile libboost_thread*.a
and I gave up. After a while I realized that the exception could be
thrown in one thread and caught (unsuccessfully) in the main thread or
some other so I googled for how to disable ASIO threads and that
really helped.
MXE uses threadapi=win32 and threading=multi, probably switching the
latter to single and recompiling boost would help as well but it seems
not to be an easy task with MXE. As I found out there's little to no
http://stackoverflow.com/questions/20859761/what-exactly-does-threading-multi-do-when-compiling-boost
and it doesn't mention any issues with exceptions) so I don't know if
it breaks something else if I change it and what exactly changes in
multithreaded boost. For instance, how to deal with exceptions in my
case. Maybe that's a flaw in ASIO itself but I'd refrain from drawing
any conclusions.
Honestly, I don't like it when an abstraction leaks this badly and
instead of added "behind the scenes" efficiency I have to deal with
uncaught exceptions that are clearly have to be caught in this
simplest piece of code.

Post by Sergey Shpikin
Good to know that at least one configuration is working, thank you for
testing! That MinGW build is for Windows, unfortunately, and I'd like
to compile on Linux for Windows.

Post by niXman

Works as expected for me using i686-6.2.0-release-posix-dwarf-rev1[1] &
boost-1.62.
[1]
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/6.2.0/threads-posix/dwarf/i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z
--
Regards, niXman
___________________________________________________
http://sourceforge.net/projects/mingw-w64/
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio