asio-users — General discussion about the asio C++ library.

Re: [asio-users] boost::asio and seccomp

[Marek K. <m-k...@mk...>]

On Mon, 17 Nov 2025 15:31:18 -0300
Vinícius dos Santos Oliveira <vin...@gm...> wrote:

> Landlock is a promising new Linux approach that won't ever replace
> seccomp, but has the potential to secure some interfaces that seccomp
> can't. Until Landlock is mature and more complete, we have to do stuff
> such as avoiding io_uring entirely within sandboxes. For Boost.Asio
> this means using the epoll backend.

Actually, I'm trying out Landlock myself right now. However, I'm not
sure if I'm using it correctly. [1]

[1]
https://codeberg.org/mark22k/crazytrace/src/commit/917755f71dd2adc0cc8f5d055f10ad5f9debf420/src/main.cpp#L139

-- 
Marek Küthe
m....@mk...
er/ihm he/him

Re: [asio-users] boost::asio and seccomp

[Marek K. <m-k...@mk...>]

On Mon, 17 Nov 2025 15:31:18 -0300
Vinícius dos Santos Oliveira <vin...@gm...> wrote:

> Em seg., 17 de nov. de 2025 às 13:09, Marek Küthe
> <m-k...@mk...> escreveu:
> > Hello,  
> 
> Hi Marek,
> 
> I have lots of experience with containerization & sandboxing on Linux
> (and FreeBSD), but very few people to talk to about it (which I do
> miss more of). Let's keep in contact after I try to help answer your
> questions.

My contact details are on my website: https://mk16.de/about_me/

> 
> > I would like to make my program more secure under Linux with seccomp.
> > My question is: how can I query which backend boost::asio uses (epoll,
> > select, etc.)?  
> 
> Boost.Asio doesn't have fallback logic. You choose which backend to
> use at compile time by defining macros.
> 
> Given most vendors disable io_uring nowadays[1], the ideal
> implementation would not work as Boost.Asio does. The ideal
> implementation would have fallback logic and try io_uring first. This
> would also help with sandboxes because seccomp is a terrible model to
> secure io_uring in capability sandboxes (io_uring communicates with
> the kernel through message writes, but seccomp only filters syscalls).
> So if Boost.Asio had fallback logic your application would be able to
> fork the process, and disable io_uring. On the forked process,
> Boost.Asio could use epoll while the parent process would use
> io_uring. That's not possible today.

However, io_uring also appears to have three syscalls:
```
$ ausyscall --dump | grep io_uring
425	io_uring_setup
426	io_uring_enter
427	io_uring_register
```

However, boost::asio does not seem to use them. So if boost::asio uses
io_uring (BOOST_ASIO_HAS_IO_URING_AS_DEFAULT), do I not need seccomp
for it?

> Landlock is a promising new Linux approach that won't ever replace
> seccomp, but has the potential to secure some interfaces that seccomp
> can't. Until Landlock is mature and more complete, we have to do stuff
> such as avoiding io_uring entirely within sandboxes. For Boost.Asio
> this means using the epoll backend.

As far as I understand, you have to explicitly enable this in the
kernel. Does Debian do this by default? If not, it's not worth my while
to look into it, as I want to deploy the program productively on Debian
later on.

> > I would also like to know which system calls boost::asio
> > uses for which Linux backend.  
> 
> io_uring doesn't use syscalls so there's no point in filtering
> syscalls to secure io_uring.
> 
> For the epoll backend, everyone does basically the same things. Just
> go through the list of syscalls and enable everything epoll-related.
> You can look at Kafel for an easy to use language to define seccomp
> policies. I wrote a few policy groups if you're interested.

I had been using libseccomp until now. Does Kafel offer any advantages?
My previous code is in
https://codeberg.org/mark22k/crazytrace/src/commit/d507ff13256d7e2f69635306924814356d35ad6e/src/seccomp.cpp
and
https://codeberg.org/mark22k/crazytrace/src/commit/d507ff13256d7e2f69635306924814356d35ad6e/src/main.cpp.

> The only weird thing about Boost.Asio is that it still relies on the
> ancient'n'fragile FIONBIO[2] instead of fcntl/O_NONBLOCK by default
> (and MSG_DONTWAIT when available to save syscalls/performance). I
> complained to Chris until he fixed almost all of my complaints.
> Nowadays you can use Boost.Asio in many models of capability
> sandboxes, but not all. The only missing piece is MSG_DONTWAIT which
> matters to avoid DoS when file descriptors are shared among untrusted
> processes (necessary for capability sandboxes).

Hmm, boost::asio seems to use fcntl for me. Do you know which syscalls
need to be enabled for FIONBIO (ioctl?) and how to check whether
boost::asio uses FIONBIO or fcntl?

> I wrote a very detailed article explaining how to develop sandboxes
> for Linux and FreeBSD, but I suspect only 2 people have actually read
> the whole thing:
> https://blog.emilua.org/2025/01/12/software-sandboxing-basics/

I currently use libcap-ng in addition to seccomp. In my opinion,
libcap-ng was much easier to use (but that may be because I know the
caps I need better than the syscalls).

> The described model is implemented in Emilua which is a runtime
> (similar to NodeJS) for LuaJIT using Boost.Asio (you can also
> configure it to use the standalone version of ASIO if you want).
> Emilua is also a container runtime. You can prototype stuff quickly in
> Lua using Emilua and implement a high-performance version in pure C++
> later if the need arises. That's the last demo I made for Emilua:
> https://www.youtube.com/watch?v=anu-onpDMBc
> 
> I'm now keeping in contact with Matthew Flatt to implement sandboxes
> for Racket. However Racket doesn't use Boost.Asio.
> 
> I'm also designing a thing to more easily implement sandboxes in C++,
> but it's still too soon to show this work.
> 
> I've tried to collaborate with JS runtime developers to implement
> sandboxes too, but every time I've left these meetings frustrated. JS
> guys have no ambition at all. They only want to mirror what NodeJS
> already does (and perhaps do the same stuff but only slightly faster).
> I have no intention to collaborate with JS communities again. I want
> to collaborate with ambitious programmers who want to do more than
> what's possible today. I don't want to collaborate with programmers
> whose souls are already dead.
> 
> > Can anyone help me with this? Is this documented anywhere?  
> 
> There's no documentation. I hope my attempts to explain seccomp,
> io_uring and Boost.Asio were useful to you.
> 
> [1] https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html
> [2] https://stackoverflow.com/a/1151077/883113
> 
> 
> _______________________________________________
> asio-users mailing list
> asi...@li...
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio


-- 
Marek Küthe
m....@mk...
er/ihm he/him

Re: [asio-users] boost::asio and seccomp

[Marek K. <m-k...@mk...>]

Thanks for your reply, Christian.

On Mon, 17 Nov 2025 17:39:17 +0100
Christian Eggers <ce...@ar...> wrote:

> at least the asio-users list looks dead to me ...

I was unsure about that too, so I wrote to boost-users (at least I
should have) as well. Is there perhaps another forum or something
similar?

> On Monday, 17 November 2025, 16:52:34 CET, Marek Küthe wrote:
> > Hello,
> > 
> > I would like to make my program more secure under Linux with seccomp.
> > My question is: how can I query which backend boost::asio uses (epoll,
> > select, etc.)?   
> 
> <disclaimer>I am not an ASIO expert</disclaimer>
> 
> As far is I understand, (boost::)asio uses epoll by default under Linux.
> This a compile time decision, not runtime. Everything is configured by macros
> which are documented here:

Thanks for confirming that. That's how I understood it too.

> https://www.boost.org/doc/libs/latest/doc/html/boost_asio/using.html#boost_asio.using.macros
> 
> The default values of the macros are determined by the values of various BOOST_ASIO_HAS_
> macros which in turn get their defaults mostly depending on the target platform.

The challenge for me now is to use the macros to determine which
backend boost::asio uses. Unfortunately, there is not a BOOST_ASIO_HAS_
for every syscall, and the logic behind how this is implemented does
not seem to be documented.

> As (boost::)asio is (by default) a header only library, you have to set those
> defines during compilation of your application (at least for the source
> files where you include the ASIO headers).
> 
> As an alternative to epoll/(p)poll/select you may also use the io_uring
> backend (requires liburing and kernel support). The release notes for Boost 1.78
> tell how to enable this:
> 
> https://www.boost.org/doc/libs/latest/doc/html/boost_asio/history.html#boost_asio.history.asio_1_22_0___boost_1_78

If I only wanted to sandbox the program for myself, that would probably
be sufficient. However, I want my program to sandbox itself using
libseccomp. Perhaps I didn't express that clearly.

> > I would also like to know which system calls boost::asio
> > uses for which Linux backend.  
> You probably may run your application under 'strace' in order to see
> all kernel calls made by your application. I would suggest starting with
> a trivial application (single process, e.g. single threaded, not too
> many i/o objects) for getting understandable output.

That's a good idea. However, in theory, in order to capture all
syscalls, I would have to compile the program in different combinations
and run strace.

-- 
Marek Küthe
m....@mk...
er/ihm he/him

Re: [asio-users] boost::asio and seccomp

[Vinícius d. S. O. <vin...@gm...>]

Em seg., 17 de nov. de 2025 às 13:09, Marek Küthe
<m-k...@mk...> escreveu:
> Hello,

Hi Marek,

I have lots of experience with containerization & sandboxing on Linux
(and FreeBSD), but very few people to talk to about it (which I do
miss more of). Let's keep in contact after I try to help answer your
questions.

> I would like to make my program more secure under Linux with seccomp.
> My question is: how can I query which backend boost::asio uses (epoll,
> select, etc.)?

Boost.Asio doesn't have fallback logic. You choose which backend to
use at compile time by defining macros.

Given most vendors disable io_uring nowadays[1], the ideal
implementation would not work as Boost.Asio does. The ideal
implementation would have fallback logic and try io_uring first. This
would also help with sandboxes because seccomp is a terrible model to
secure io_uring in capability sandboxes (io_uring communicates with
the kernel through message writes, but seccomp only filters syscalls).
So if Boost.Asio had fallback logic your application would be able to
fork the process, and disable io_uring. On the forked process,
Boost.Asio could use epoll while the parent process would use
io_uring. That's not possible today.

Landlock is a promising new Linux approach that won't ever replace
seccomp, but has the potential to secure some interfaces that seccomp
can't. Until Landlock is mature and more complete, we have to do stuff
such as avoiding io_uring entirely within sandboxes. For Boost.Asio
this means using the epoll backend.

> I would also like to know which system calls boost::asio
> uses for which Linux backend.

io_uring doesn't use syscalls so there's no point in filtering
syscalls to secure io_uring.

For the epoll backend, everyone does basically the same things. Just
go through the list of syscalls and enable everything epoll-related.
You can look at Kafel for an easy to use language to define seccomp
policies. I wrote a few policy groups if you're interested.

The only weird thing about Boost.Asio is that it still relies on the
ancient'n'fragile FIONBIO[2] instead of fcntl/O_NONBLOCK by default
(and MSG_DONTWAIT when available to save syscalls/performance). I
complained to Chris until he fixed almost all of my complaints.
Nowadays you can use Boost.Asio in many models of capability
sandboxes, but not all. The only missing piece is MSG_DONTWAIT which
matters to avoid DoS when file descriptors are shared among untrusted
processes (necessary for capability sandboxes).

I wrote a very detailed article explaining how to develop sandboxes
for Linux and FreeBSD, but I suspect only 2 people have actually read
the whole thing:
https://blog.emilua.org/2025/01/12/software-sandboxing-basics/

The described model is implemented in Emilua which is a runtime
(similar to NodeJS) for LuaJIT using Boost.Asio (you can also
configure it to use the standalone version of ASIO if you want).
Emilua is also a container runtime. You can prototype stuff quickly in
Lua using Emilua and implement a high-performance version in pure C++
later if the need arises. That's the last demo I made for Emilua:
https://www.youtube.com/watch?v=anu-onpDMBc

I'm now keeping in contact with Matthew Flatt to implement sandboxes
for Racket. However Racket doesn't use Boost.Asio.

I'm also designing a thing to more easily implement sandboxes in C++,
but it's still too soon to show this work.

I've tried to collaborate with JS runtime developers to implement
sandboxes too, but every time I've left these meetings frustrated. JS
guys have no ambition at all. They only want to mirror what NodeJS
already does (and perhaps do the same stuff but only slightly faster).
I have no intention to collaborate with JS communities again. I want
to collaborate with ambitious programmers who want to do more than
what's possible today. I don't want to collaborate with programmers
whose souls are already dead.

> Can anyone help me with this? Is this documented anywhere?

There's no documentation. I hope my attempts to explain seccomp,
io_uring and Boost.Asio were useful to you.

[1] https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html
[2] https://stackoverflow.com/a/1151077/883113

[asio-users] boost::asio and seccomp

[Marek K. <m-k...@mk...>]

Hello,

I would like to make my program more secure under Linux with seccomp.
My question is: how can I query which backend boost::asio uses (epoll,
select, etc.)? I would also like to know which system calls boost::asio
uses for which Linux backend.

Can anyone help me with this? Is this documented anywhere?

Best regards,
Marek Küthe

-- 
Marek Küthe
m....@mk...
er/ihm he/him

[asio-users] Meaning for ASIO_CONCURRENCY_HINT_SAFE changed?

[Vinícius d. S. O. <vin...@gm...>]

ASIO_CONCURRENCY_HINT_SAFE used to mean the default value that is
passed to io_context[1] which means you may call run() from multiple
threads (that's the default after all).

The docs for 1.88 now state that ASIO_CONCURRENCY_HINT_SAFE means
scheduler/concurrency_hint=1 which is different from the default
io_context constructor.

[1] https://live.boost.org/doc/libs/1_86_0/doc/html/boost_asio/overview/core/concurrency_hint.html
[2] https://www.boost.org/doc/libs/1_88_0/doc/html/boost_asio/overview/core/configuration.html

-- 
Vinícius dos Santos Oliveira

[asio-users] Handle interruptions while performing sync handshake on TLS sockets

[Amirsaman M. <ami...@mo...>]

Hi there,

My understanding from the code is that the public-facing API
<https://github.com/chriskohlhoff/asio/blob/62481a25be6cf78cbe714419a4462fd89bd84ab9/asio/include/asio/ssl/stream.hpp#L406-L421>
does not allow continuing interrupted handshakes, since the API doesn't
inform the caller about the number of transferred bytes during the latest
interrupted attempt.

The implementation for `detail::handshake_op` supports retrying and
advancing buffers, but it doesn't handle interrupted syscalls and delegates
those to the caller. However, the caller cannot simply retry the handshake
as consumed bytes off the wire are no longer available.

Am I missing something or the caller is expected to drop the connection?

-- 

*{* name     : "Amirsaman Memaripour",
  title    : "Staff Engineer",
  location : "New York, NY",
  twitter  : "@MongoDB
<https://www.google.com/url?q=https%3A%2F%2Ftwitter.com%2Fmongodb&sa=D&sntz=1&usg=AFQjCNGEAIAhZyZhF7Z9ORWsRliTuc-2dg>
",
  facebook : "MongoDB
<https://www.google.com/url?q=https%3A%2F%2Fwww.facebook.com%2Fmongodb&sa=D&sntz=1&usg=AFQjCNGPMcaFBzmWsh-MpaWeTH6vMQoDIg>
" *}*

[asio-users] Software Sandboxing

[Vinícius d. S. O. <vin...@gm...>]

I published a blog post today explaining the basics on how to properly
sandbox (discretionary privilege dropping) programs written using
Emilua (the ASIO-based execution engine for Lua programs):
https://blog.emilua.org/2025/01/12/software-sandboxing-basics/

I've tried my best to make the article hopefully useful to programmers
from any language so the few Lua samples in the article are only there
to illustrate the concepts. Some of the topics found in the article:

* UNIX basics focusing on Linux and FreeBSD.
* A few details on how ASIO deals with file descriptors.
* General sandboxing concepts and how to apply them in Linux and FreeBSD.
* The actor model and capability-based security (and how to combine them).
* Oblivious sandboxing to reuse unmodified code in sandboxes.
* Threat models.
* Seccomp, Landlock, Capsicum, ...
* A few guidelines for the C programmer.

The article was becoming quite long so I decided to end it sooner, and
leave other topics I wanted to talk about to future blog posts.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

[asio-users] timer does only work once when building with BOOST_ASIO_HAS_IO_URING_AS_DEFAULT

[Christian E. <CE...@gm...>]

OS: linux-6.6.49
Boost: 1.84.0

I have taken an older "blocking read with timeout" example from here:
https://lists.boost.org/Archives/boost/2007/04/120339.php

This example (updated source code below) works fine as long as using
the epoll reactor (simply try with a non connected UART, the program
should finish after two seconds).

But as soon as I switch to the io_uring implementation (by defining
BOOST_ASIO_HAS_IO_URING and BOOST_ASIO_HAS_IO_URING_AS_DEFAULT), the
2nd timeout is not reached (program exits after 301 seconds).

When I only define BOOST_ASIO_HAS_IO_URING (without BOOST_ASIO_HAS_IO_URING_AS_DEFAULT),
the program works fine. Additionally I recognized that the behavior
depends on the timing. When single stepping in a debugger, also the
2nd timeout works correctly.

Q: Is the example program correct?
Q: Why does it not work as expected with io_uring?

regards,
Christian


#include <chrono>
#include <iostream>

#include <boost/asio.hpp>
#include <boost/bind/bind.hpp>
#include <boost/optional.hpp>
#include <boost/system/error_code.hpp>

using namespace boost;
using namespace boost::asio;
using namespace std::chrono;
using namespace boost::placeholders;
using namespace boost::system;

void set_result(optional<boost::system::error_code>* a, boost::system::error_code b)
{
        a->reset(b);
}

template <typename MutableBufferSequence>
void read_with_timeout(io_context& io_context, serial_port& port,
                const MutableBufferSequence& buffers)
{
        optional<error_code> timer_result;
        steady_timer timer(io_context);
        timer.expires_after(seconds(1));
        timer.async_wait(
                boost::bind(set_result, &timer_result, _1));

        optional<error_code> port_result;
        async_read(port, buffers,
                boost::bind(set_result, &port_result, _1));

        io_context.restart();
        while (io_context.run_one())
        {
                if (timer_result)
                        port.cancel();
                else if (port_result)
                        timer.cancel();
        }

        if (port_result && *port_result)
                throw system_error(*port_result);
}

int main(int argc, char *argv[])
{
        io_context io_context;
        serial_port port(io_context, "/dev/ttymxc6");
        char buf[4096];

        try
        {
                std::cout << "Read (1) ...\n";
                read_with_timeout(io_context, port, buffer(buf));
        }
        catch (const std::exception& e)
        {
                std::cerr << "Exception: " << e.what() << '\n';
        }

        try
        {
                std::cout << "Read (2) ...\n";
                read_with_timeout(io_context, port, buffer(buf));
        }
        catch (const std::exception& e)
        {
                std::cerr << "Exception: " << e.what() << '\n';
        }
}

Re: [asio-users] [ANN] emilua-beast 1.0

[Vinícius d. S. O. <vin...@gm...>]

Em sáb., 31 de ago. de 2024 às 16:38, Vinnie Falco
<vin...@gm...> escreveu:
> On Sat, Aug 31, 2024 at 4:33 AM Vinícius dos Santos Oliveira
> <vin...@gm...> wrote:
> > Would this choice be acceptable for Lua bindings even if it deviates from the C++ API?
>
> In short, yes it is acceptable.

Okay, I've also added bindings to Beast errors and released a new
version. URL to the docs changed to
<https://docs.emilua.org/beast/1.1/ref/beast.html>.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

Re: [asio-users] [ANN] emilua-beast 1.0

[Vinnie F. <vin...@gm...>]

On Sat, Aug 31, 2024 at 4:33 AM Vinícius dos Santos Oliveira
<vin...@gm...> wrote:
> Boost.Beast C++ API is different. Would this choice be acceptable for Lua bindings even if it deviates from the C++ API?

In short, yes it is acceptable. Adding fields to a client handshake is
a common operation, and there is no reason not to have this API. We
could in theory add it to Beast, someone just needs to open an issue.
However, your implementation is also OK.

Thanks

Re: [asio-users] [ANN] emilua-beast 1.0

[Vinícius d. S. O. <vin...@gm...>]

Here's what I had in mind for the client role:
https://gitlab.com/emilua/beast/-/commit/4c7059cea27a65fbf302fa9a866932563a09de2f

In retrospect, my previous email wasn't very clear in this part. So I
decided to just commit some code to show what I had in mind. Now you can
use Lua code such as the following to insert extra headers in the client
handshake:

ws:handshake(host, '/ws/api/v2', { origin = host })

Boost.Beast C++ API is different. Would this choice be acceptable for Lua
bindings even if it deviates from the C++ API? That's what I was trying to
ask. If it's okay, I can tag a new release with this code and release a new
ArchLinux package.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

Re: [asio-users] [ANN] emilua-beast 1.0

[Vinícius d. S. O. <vin...@gm...>]

Em sex., 30 de ago. de 2024 às 19:24, Vinnie Falco
<vin...@gm...> escreveu:
> Would it help if Beast offered some new WebSocket APIs that create the
> Upgrade response and return it to you? And we could add extra
> websocket::stream APIs to perform the handshake assuming the caller
> has already sent the upgrade response?

Back at emilua-0.5 when WebSocket+HTTP were part of the core package,
that's how I've designed the interface for extra headers:
<https://docs.emilua.org/api/0.5/ref/websocket.html#new-websocket>.
However back in 0.5, I wasn't really worried about following
Boost.Beast conventions.

This new plugin mirrors Boost.Beast interfaces very closely and so
far, only existing Boost.Beast methods are exposed. For the extra
headers, I can follow the same design (add an extra parameter for
handshake() in the Lua interfaces to represent the HTTP extra request
headers... and inject them in the C++-side through the decorator
interface). Would you consider that acceptable for Lua bindings for
Beast? Having the author's approval would give me confidence in this
design and I'd be able to solve the client case today. The server role
is not as urgent and could enjoy some more time on design iterations.

I don't think creating the upgrade response and returning it would be
the way to go in emilua. Emilua needs an embedded HTTP server (never
in core though). If one is inspecting HTTP headers, I feel the way to
go would be to have an actual HTTP server. Beast already has two
interfaces for separate HTTP server implementations:

* Passing headers extracted from the HTTP layer:
https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/ref/boost__beast__websocket__stream/accept/overload5.html
* Generating HTTP response headers:
https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/using_websocket/decorator.html

Likewise, Boost.Beast already provides an embedded HTTP server. So
maybe offer it as well in this plugin. If anyone writes it, I can
approve the PR. I can also give admin powers in this repo to someone
affiliated with Boost.Beast.

However, on my own time, I don't see myself writing bindings for
Beast's HTTP abstractions. I plan on spending time to write a curl
plugin as lots of folks will only ever trust curl to handle HTTP
streams.

Thoughts?


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

Re: [asio-users] [ANN] emilua-beast 1.0

[Vinnie F. <vin...@gm...>]

On Fri, Aug 30, 2024 at 2:46 PM Vinícius dos Santos Oliveira
<vin...@gm...> wrote:
...you won't find beast::websocket::stream_base::decorator to
change/examine HTTP fields.

Would it help if Beast offered some new WebSocket APIs that create the
Upgrade response and return it to you? And we could add extra
websocket::stream APIs to perform the handshake assuming the caller
has already sent the upgrade response?

Thanks

[asio-users] [ANN] emilua-beast 1.0

[Vinícius d. S. O. <vin...@gm...>]

Last year I announced emilua here as Lua bindings for Boost.ASIO.

Starting at version 0.6 at the beginning of this year, I've removed all
HTTP/WebSocket classes from the core package as I've felt they don't belong
in the core.

Today I'm announcing emilua-beast 1.0 which is something I've hacked
together over this week:
https://docs.emilua.org/beast/1.0/ref/beast.websocket.html

Code is available at <https://gitlab.com/emilua/beast>.

This new plugin only exposes WebSocket abstractions. However I've spent a
good time re-reviewing it several times to make sure it's usable in
production (code quality wise). Basically everything exposed under
boost::beast::websocket::stream is present here... except for callbacks.
Lua has true coroutines which means suspending anywhere. C++ callback-based
interfaces don't work well for emilua. Therefore you won't find
beast::websocket::stream_base::decorator to change/examine HTTP fields.

I'll have to think of a callback-less interface to interact with HTTP
fields within WebSocket context as some HTTP fields such as origin and
sec-websocket-protocol are too important to ignore (you'll be unable to
connect to many public endpoint if you don't set these fields). Feedback
welcome.

I'll be using this plugin to write a nostr client which parsers multimedia
content in secure sandboxes so it should see some real-world usage
hopefully.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

[asio-users] The git repo in sf is not update to date

[Li R. <lx...@ho...>]

Hello list and  Christopher

I am a newbie to asio, and learning about it. I found many things in git repo didn’t match the document. That makes me very confused since I don’t have much confidence about my c++, thinking there are some magic behind it.
Until now, two months later, I noticed the version in the git repo at sf are not the version the document were talking about.

I would like to suggest submit a warning in the document that nobody download code from git in the first place.

Sincerely
Randy
Sent from my iPad

Re: [asio-users] Usage of FIONBIO causes problems on FreeBSD

[Vinícius d. S. O. <vin...@gm...>]

The problem was partially fixed in commit
https://github.com/chriskohlhoff/asio/commit/c0fbbddad10d342e9fbc6a7c13411ffedaf4bd31

However, that still causes problems for FreeBSD and other BSD systems.
First, kqueue doesn't implement ioctls (FIONBIO is an ioctl), so
you're still prevented from having a nested kqueue (through
asio::posix::stream_descriptor) to use interfaces that are not exposed
by Boost.Asio.

One example of such interfaces not exposed by Boost.Asio is to await
for a subprocess to finish. In FreeBSD, you have procdesc file
descriptors returned by pdfork(). However you can't wait for readiness
on this file descriptor. Instead, you have to watch for
EVFILT_PROCDESC on kqueue:
https://gitlab.com/emilua/emilua/-/blob/v0.6.0/src/freebsd/system/spawn.cpp#L111
(this code will consume 100% CPU on today's Boost.Asio because of the
FIONBIO-on-the-nested-kqueue-fd bug). For other BSDs, you use
NOTE_EXIT on an EVFILT_PROC instead of a EVFILT_PROCDESC to just
stumble on the same Boost.Asio bug.

For FreeBSD, a new workaround that is now possible due to this commit
is to just call cap_ioctls_limit() on the nested kqueue file
descriptor to force ENOTCAPABLE. Other BSDs can't use this workaround.
I'll use this workaround in the future, but (1) other BSD systems are
left to rot, and (2) this workaround doesn't solve all the problems.

I don't even understand why Boost.Asio is setting non-blocking mode in
a call to asio::posix::stream_descriptor::async_wait() to begin with.
async_wait() is not the operation per se, but the event to wait for
before doing the actual operation. Adding a fd on the set for
readiness-waiting per se can't block, and neither FIONBIO nor fcntl
makes any sense here. None of this current Boost.Asio behavior makes
sense.

Furthermore, Boost.Asio still is performing random ioctls for file
descriptors that you might have received from untrusted processes.
Most users won't care about it given most users control the origin of
all file descriptors, but I have a project where this matters. Ideally
I should be able to just disable this FIONBIO mess altogether and not
worry about it ever again.

And I'm still out-of-github. I asked a friend to submit a patch
previously, but the patch was just ignored:
https://github.com/chriskohlhoff/asio/pull/1406 (the second paragraph
already explained problems not fixed in the commit that landed on the
main repo, so I assume people only read the first paragraph and
ignored everything else). It takes years to synchronize the supply
chain across downstream distributors, so it's really frustrating to
have a partially fixed patch when the original patch already fixed all
the problems for the interested parties.

Em qua., 6 de dez. de 2023 às 22:57, Vinícius dos Santos Oliveira
<vin...@gm...> escreveu:
>
> I've been facing problems trying to use Github, so I can't report issues (nor send PRs) through Github.
>
> For now, I'll just report issues here in the list.
>
> In the last months I made extensive use of Boost.Asio on FreeBSD and I faced some problems. Almost all of them were related to indiscriminate usage of FIONBIO. By doing a quick search on Google I found out this ioctl() kinda predates POSIX and had inconsistent behaviour among different systems and even different objects in the same system. So it was a surprise to learn that Boost.Asio favours FIONBIO over fcntl().
>
> A quick search for FIONBIO on ASIO's repo reveals it's not the first time this ioctl causes problems: https://github.com/chriskohlhoff/asio/commit/607f99ba80df71f1a96f0df71725059ee71e46ff
>
> For FreeBSD, the first problem I faced was related to Capsicum. Sending a Capsicum-protected file descriptor over an UNIX socket to a Boost.Asio process will block usage of ioctls on the file descriptor. The call for FIONBIO fails with ENOTCAPABLE and Boost.Asio refuses to work with the object for no good reason.
>
> The second problem I faced was trying to use posix::stream_descriptor to monitor a kqueue file descriptor. Boost.Asio doesn't try to support every feature the underlying system has so it offers some escape latches and posix::stream_descriptor is just one of these. However, posix::stream_descriptor will perform FIONBIO on the underlying descriptor (which of course isn't supported on kqueue file descriptors nor on many other file descriptors). This will cause async_wait() to fail.
>
> I think any usage of FIONBIO on Boost.Asio codebase should just be removed altogether. Recently ASIO started to require C++11 which is way way newer than fcntl() so it doesn't make sense to still depend on such problematic ioctl().
>
> I have more issues to report (not all of them related to FreeBSD), but indiscriminate usage of ioctls (FIONBIO) is one that really bites my back and it's the only one I feel compelled to report sooner even if Github is playing games with me.
>
>
> --
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/



-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

Re: [asio-users] boost-asio and asio coexistance

[<mat...@gm...>]

Thanks Vinnie,

I have considered that and unfortunately its not going to work for this
application.

I think I will need to backport some of the lib2 code.

The biggest pieces I see are the newer code uses any_io_executor which if
I'm understanding it, could be changed to use the older executor wrapper.
Then there is the use of async_initiate.  This one is not as clear to me
but I think I can change it to async_result but need to look into it more.

Thanks, Matt.

On Fri, Feb 9, 2024 at 6:16 PM Vinnie Falco <vin...@gm...> wrote:

> On Fri, Feb 9, 2024 at 2:51 PM <mat...@gm...> wrote:
>
>> I guess my question is about best practices for running both asio
>> versions in the same application, in other words handling both
>> io_context::run()?
>>
>
> Well if you want to call `io_context::run()` you will need a separate
> thread for each. I suspect this is not what you want, so instead you might
> write:
>
>     while( is_running() ) // your function
>     {
>         ctx0.run_for( std::chrono::milliseconds(50) );
>         ctx1.run_for( std::chrono::milliseconds(50) );
>     }
>
> You will need to figure out what works best for your application in terms
> of dividing the time between the contexts.
>
> Thanks
>
>
> _______________________________________________
> asio-users mailing list
> asi...@li...
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>

Re: [asio-users] boost-asio and asio coexistance

[Vinnie F. <vin...@gm...>]

On Fri, Feb 9, 2024 at 2:51 PM <mat...@gm...> wrote:

> I guess my question is about best practices for running both asio versions
> in the same application, in other words handling both io_context::run()?
>

Well if you want to call `io_context::run()` you will need a separate
thread for each. I suspect this is not what you want, so instead you might
write:

    while( is_running() ) // your function
    {
        ctx0.run_for( std::chrono::milliseconds(50) );
        ctx1.run_for( std::chrono::milliseconds(50) );
    }

You will need to figure out what works best for your application in terms
of dividing the time between the contexts.

Thanks

[asio-users] boost-asio and asio coexistance

[<mat...@gm...>]

Hi all,

The ASIO website states that boost-asio and asio can coexist in the same
application.

I have a case where I need to do this.

The application uses two libraries, lib1 and lib2.

Lib1 uses asio version 1.12.0 and cannot be updated.  Lib2 can use either
asio or boost-asio but cannot use a version < 1.16.0 of asio.

I guess my question is about best practices for running both asio versions
in the same application, in other words handling both io_context::run()?

Can anyone point me to an example of doing this?

Thanks, Matt.

[asio-users] Green Hills Integrity

[Mark W. <mwi...@gm...>]

Has anyone attempted to compile and run Boost ASIO on Green Hills Integrity
OS?

[asio-users] asio::error::basic_errors::not_supported is missing

[Vinícius d. S. O. <vin...@gm...>]

On POSIX systems, asio::error::basic_errors will be just an alias for
values that ASIO uses from std::system_category().

One of these is operation_not_supported (which is EOPNOTSUPP). However
EOPNOTSUPP may alias ENOTSUP on some systems. For Linux and FreeBSD,
these errno values are the same. For OpenBSD, macOS, and a few others
they differ.

When a composed operation throws ENOTSUP, the caller might
accidentally catch EOPNOTSUPP on Linux or FreeBSD. There isn't really
any good answer here. However I think Boost.Asio should just define
asio::error::basic_errors::not_supported and document that
not_supported and operation_not_supported might be aliases on some
systems (they are on Linux and FreeBSD). That's what C++11 already
does in a way by including both definitions so Boost.Asio could just
follow along as well.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

[asio-users] Usage of FIONBIO causes problems on FreeBSD

[Vinícius d. S. O. <vin...@gm...>]

I've been facing problems trying to use Github, so I can't report issues
(nor send PRs) through Github.

For now, I'll just report issues here in the list.

In the last months I made extensive use of Boost.Asio on FreeBSD and I
faced some problems. Almost all of them were related to indiscriminate
usage of FIONBIO. By doing a quick search on Google I found out this
ioctl() kinda predates POSIX and had inconsistent behaviour among different
systems and even different objects in the same system. So it was a surprise
to learn that Boost.Asio favours FIONBIO over fcntl().

A quick search for FIONBIO on ASIO's repo reveals it's not the first time
this ioctl causes problems:
https://github.com/chriskohlhoff/asio/commit/607f99ba80df71f1a96f0df71725059ee71e46ff

For FreeBSD, the first problem I faced was related to Capsicum. Sending a
Capsicum-protected file descriptor over an UNIX socket to a Boost.Asio
process will block usage of ioctls on the file descriptor. The call for
FIONBIO fails with ENOTCAPABLE and Boost.Asio refuses to work with the
object for no good reason.

The second problem I faced was trying to use posix::stream_descriptor to
monitor a kqueue file descriptor. Boost.Asio doesn't try to support every
feature the underlying system has so it offers some escape latches and
posix::stream_descriptor is just one of these. However,
posix::stream_descriptor will perform FIONBIO on the underlying descriptor
(which of course isn't supported on kqueue file descriptors nor on many
other file descriptors). This will cause async_wait() to fail.

I think any usage of FIONBIO on Boost.Asio codebase should just be removed
altogether. Recently ASIO started to require C++11 which is way way newer
than fcntl() so it doesn't make sense to still depend on such problematic
ioctl().

I have more issues to report (not all of them related to FreeBSD), but
indiscriminate usage of ioctls (FIONBIO) is one that really bites my back
and it's the only one I feel compelled to report sooner even if Github is
playing games with me.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

[asio-users] Emilua 0.5 released

[Vinícius d. S. O. <vin...@gm...>]

Emilua was announced here a few months ago as an execution engine for Lua
built on top of Boost.Asio. Now a new version has been released.

The focus for this release was refactoring the internals so it'd be easier
to build single-binary applications in the future. As an example of this
work, now Emilua only ever queries the filesystem if nothing is found on
the in-memory module cache. This allows you to pre-populate the module
cache with all Lua files that make up your Lua program from main(). Future
releases will improve this support even further by focusing on decreasing
module cache populating time.

So, what's in for C++ programmers? Not every piece of your C++ program is
critical. For boring tasks where performance doesn't matter as much, you
can just write it in Lua and enjoy a tight integration with
asio::io_context so it communicates adequately with your C++ code. You can
also set up some C++ routines to be called from Lua. There's a new tutorial
on how to embed this runtime in your C++ programs: <
https://docs.emilua.org/api/0.5/tutorial/embedding.html>.

Aside from this work, there are a couple of big features in this release as
well:

   - Support for Linux's Landlock.
   - Support for FreeBSD's Capsicum.

These are the sandboxing technologies that better accommodate
compartmentalised application development built around capabilities.

The full changelog is available at <
https://docs.emilua.org/api/0.5/changelog.html>.

This is also the last version that's going to include builtin HTTP and
WebSocket support. From 0.6 onwards you'll have to install a separate
plugin to have access to these features.

If you're writing libraries based on Boost.Asio, you might find it useful
to write Lua bindings using Emilua. This would give you:

   - A test bench to quickly iterate over your high-level API by hiding
   unimportant boilerplate found on C++ and ASIO code.
   - A cleaner language to write unit tests with.
   - A larger public for your API (Lua users).

I also found several bugs with Boost.Asio on FreeBSD while working on this
release, but I'm struggling to report them using Github. I'm not sure how
to proceed here. Is there an alternative way to send reports and pull
requests w/o Github?


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

[asio-users] Does co_spawn start a coroutine lazily ?

[Eduardo P. <edu...@gm...>]

I am using asio and C++20 coroutines to wait for a socket to become
ready for read or write.

Please, see example below:

asio::awaitable<void>
waitForIO(asio::ip::tcp::socket& socket, asio::socket_base::wait_type waitType)
{
    std::cout << "start waiting for " << (waitType
==asio::socket_base::wait_type::wait_write ? "write" : "read") <<
std::endl;              // line 1
    co_await socket.async_wait(waitType,  use_awaitable);

                             // line 2
    std::cout << "socket became ready to " << (waitType
==asio::socket_base::wait_type::wait_write ? "write" : "read") <<
std::endl; // line 3
}

void startIO()
{
    std::cout << "spawning write coroutine" << std::endl;

                                // line 4
    asio::co_spawn(socket->get_executor(), waitForIO(socket, socket,
asio::socket_base::wait_type::wait_write), asio::detached); // line 5
    std::cout << "spawning read coroutine" << std::endl;

                               // line 6
    asio::co_spawn(socket->get_executor(), waitForIO(socket,
asio::socket_base::wait_type::wait_read), asio::detached);
// line 7
}

Note: At the point where I am spawning the coroutines the respective
io executor is already running.

I assume I will always get the sequence (co_spawn immediately makes
coroutine to execute line 2 - wait for read/write):
1. spawning write coroutine
2. start waiting for write
3. spawning read coroutine
4. start waiting for read

I am wondering whether co_spawn can instead produce sequences like below:

A - does not immediately start to wait for read or write:
1. spawning write coroutine
2. spawning read coroutine
3. start waiting for write
4. start waiting for read

B - Becomes ready to write (or socket is cancelled) before waiting for read:
1. spawning write coroutine
2. spawning read coroutine
3. start waiting for write
4. socket became ready to write
5. start waiting for read

Thanks,
Eduardo Panisset.