This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Networking TS implementation
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Sat, 17 Oct 2015 16:46:15 +0100
- Subject: Networking TS implementation
- Authentication-results: sourceware.org; auth=none
I have enough of the proposed Networking TS [1] implemented for this
to work correctly:
#include <experimental/net>
#include <iostream>
using namespace std::experimental::net;
int main()
{
io_context ctx;
ip::tcp::resolver resolv(ctx);
for (auto& r : resolv.resolve("gcc.gnu.org", "http"))
std::cout << "http://gcc.gnu.org is " << r.endpoint() << "\n\n";
using namespace std::chrono_literals;
system_timer timer(ctx, 5s);
timer.async_wait([](std::error_code e) {
if (e == std::errc::operation_canceled)
std::cout << "Timer cancelled\n\n";
else
std::cout << "Ding ding!\n\n";
});
ip::tcp::acceptor acceptor(ctx, ip::tcp::endpoint(ip::tcp::v4(), 55555));
std::cout << "Listening on " << acceptor.local_endpoint() << '\n';
acceptor.async_accept( [&](auto e, ip::tcp::socket sock){
if (!e)
{
std::cout << "Connection from " << sock.remote_endpoint() << '\n';
sock.send(buffer("Hello\r\n", 7));
}
timer.cancel();
});
std::cout << "Ran " << ctx.run() << " asynchronous I/O operations.\n";
}
Which depending whether anything connects to the socket within 5s or
not will print one of the following:
----------------------------------------
$ ./a.out
http://gcc.gnu.org is 209.132.180.131:80
Listening on 0.0.0.0:55555
Connection from 127.0.0.1:57104
Timer cancelled
Ran 2 asynchronous I/O operations.
$
$
$ ./a.out
http://gcc.gnu.org is 209.132.180.131:80
Listening on 0.0.0.0:55555
Ding ding!
Connection from 127.0.0.1:57122
Ran 2 asynchronous I/O operations.
----------------------------------------
i.e. sockets and async operations using io_context work OK.
It's still missing socket iostreams, parts of the use_future
completion token handling, and system_context needs some work
(currently it uses a "thread pool" hardcoded to one thread).
Some of the design is definitely sub-optimal, but that's why it's
"experimental", right :-)
Do we want it on trunk for GCC 6 in this incomplete state?
I don't want a repeat of the <regex> situation where we have
non-functional code released, but in this case the missing parts won't
even compile, and if it goes on to trunk I don't plan to leave them
missing for long!
[1]: http://wg21.link/p0112r0#network.proposed_text