[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bmake inefficiencies
01.02.2021 07:58:26 Simon J. Gerraty <sjg%juniper.net@localhost>:
> Martin Husemann <martin%duskware.de@localhost> wrote:
>> [External Email. Be cautious of content]
>> On Sun, Jan 31, 2021 at 12:41:47PM -0800, Simon J. Gerraty wrote:
>>> David Holland <dholland-current%netbsd.org@localhost> wrote:
>>>> "static volatile sig_atomic_t reap_children;"
>>> I chose int (which is what sig_atomic_t is) for portability.
>> No, it is not int - several NetBSD architectures use long.
> Sorry, the one I checked as int, but I don't see that it should really
> matter? int should be the type that any architecture deals with most
According to https://en.cppreference.com/w/c/program/sig_atomic_t, it has been available since C90, so don't worry about portability.
There might be architectures where atomic memory access must happen in units of 64 bit. If you use a 32-bit int, this might result in load64 + mix + store64 instead of a single store32 (at whatever implementation level of the memory), which is not atomic anymore.
Main Index |
Thread Index |