This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Networking TS implementation


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]