Bruno Haible wrote:
> Eric Wong wrote:
> > > How would setting up a pipe or eventfd help with a communication
> > > problem between threads in the same process? I thought these were
> > > for communication between processes.
> >
> > The "self-pipe trick" is a common idiom in Unix for signal
> > h
On Tue, Feb 9, 2021 at 6:07 PM Bruno Haible wrote:
> Maybe I didn't describe accurately the situation I am asking for.
> I'm not attempting to transform a program to an event-based engine.
> I'm looking to let signal handlers (SIGTERM, SIGSEGV, SIGWINCH, etc.)
> read and traverse data structures t
On 2/9/21 5:21 PM, Eric Wong wrote:
I know the (C)Ruby VM uses it internally (or eventfd on Linux);
I think CPython's GVL does, too.
GNU Make does too. It's where I learned of the trick.
Eric Wong wrote:
> > How would setting up a pipe or eventfd help with a communication
> > problem between threads in the same process? I thought these were
> > for communication between processes.
>
> The "self-pipe trick" is a common idiom in Unix for signal
> handling; especially when pselect/pp
On Tue, Feb 9, 2021 at 5:01 PM Bruno Haible wrote:
>
> Ben Pfaff wrote:
> > Building an RCU implementation isn't necessarily difficult (I have done it,
> > but the implementation isn't suitable for gnulib).
> >
> > There is a liburcu that is under LGPL v2.1: https://liburcu.org/
>
> Thanks for the
Bruno Haible wrote:
> Hi Eric,
>
> Eric Wong wrote:
> > I would've recommended just using a pipe, socket or eventfd;
>
> How would setting up a pipe or eventfd help with a communication
> problem between threads in the same process? I thought these were
> for communication between processes.
Th
Hi Eric,
Eric Wong wrote:
> I would've recommended just using a pipe, socket or eventfd;
How would setting up a pipe or eventfd help with a communication
problem between threads in the same process? I thought these were
for communication between processes.
Bruno
Ben Pfaff wrote:
> On Sun, Feb 7, 2021 at 2:57 PM Bruno Haible wrote:
> > (2) Let the signal handler work only on immutable copies of the data
> > structure. Whenever the other code manipulates the data structure,
> > it creates an immutable copy of it, for the signal handler t
* m4/extern-inline.m4 (gl_EXTERN_INLINE): __header_inline is defined in
but the header is not included and as result
_GL_EXTERN_INLINE doesn't work as intended on macOS.
Signed-off-by: Roman Bolshakov
---
Hi,
The issue prevents -O1/-O0 compilation of libtasn1 on macOS:
https://gitlab.com/gn
On 2/9/21 11:42 AM, Adhemerval Zanella wrote:
Trying to sync gnulib with glibc code, this patch trigger some regression
on glibc testcases:
Thanks for letting me know. That's odd, as I didn't find any regressions
when I synced. I do know of remaining bugs and will add these to my list.
Hi Paul,
Trying to sync gnulib with glibc code, this patch trigger some regression
on glibc testcases:
FAIL: posix/tst-boost
FAIL: posix/tst-pcre
FAIL: posix/tst-rxspencer
FAIL: posix/tst-rxspencer-no-utf8
$ grep -n "FAIL rm" posix/tst-boost.out
445:FAIL rm[1] 3..-1 != expected 2..3
448:FAIL rm[
11 matches
Mail list logo
