Theo Buehler wrote:
> > I'm not sure if there is much value in percolating the error upwards through
> > tls_init() into a careful termination provides a huge amount of value
> > because
> > the error cannot be resolved without proper build & library support.
>
> Maybe not, but
> I'm not sure if there is much value in percolating the error upwards through
> tls_init() into a careful termination provides a huge amount of value because
> the error cannot be resolved without proper build & library support.
Maybe not, but tls_config_new() can fail for many reasons, so its
https://pubs.opengroup.org/onlinepubs/009695299/functions/pthread_once.html
POSIX does not specify that pthread_once() can return ENOSYS. That is a
weird decision to make in libc.
I'm not sure if there is much value in percolating the error upwards through
tls_init() into a careful termination
Hello everyone,
During the process of porting latest changes of OpenBSD's relayd to FreeBSD, I stumbled upon an
interesting issue. One of them is that the HCE subprocess of relayd gets a SIGSEGV, brining down all
the other relayd subprocesses. Here's how it looks like on the command-line:
So this basically converts the flag into a proper reference?
If you go back to 4.4BSD, there's another aspect which was different:
I believe vnodes weren't allocated dynamically, but came out of a fixed
and therefore the recycling behaviour was different. Or maybe some
kernel code had a subtle
On Tue, May 24, 2022 at 02:16:44PM +0200, Martin Pieuchot wrote:
> On 19/05/22(Thu) 13:33, Alexander Bluhm wrote:
> > On Tue, May 17, 2022 at 05:43:02PM +0200, Martin Pieuchot wrote:
> > > Andrew, Alexander, could you test this and report back?
> >
> > Panic "vref used where vget required" is
