Re: bmake inefficiencies

[Roland Illig <roland.illig%gmx.de@localhost>]

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
> naturally.

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.