Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: "White House to Developers: Using C or C++ Invites Cybersecurity
 Risks"
Date: Fri, 8 Mar 2024 15:15:36 +0000
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <usfa2o$1orr3$1@dont-email.me>
References: <us0brl$246bf$1@dont-email.me> <us1lb5$2f4n4$1@dont-email.me>
 <us2lfh$2ltj3$5@dont-email.me> <us2s96$2n6h3$6@dont-email.me>
 <us3155$2of1i$3@dont-email.me> <us4c66$346tp$3@dont-email.me>
 <us5d6f$3besu$3@dont-email.me> <20240305005948.00002697@yahoo.com>
 <us5u16$3eidj$2@dont-email.me> <20240305111103.00003081@yahoo.com>
 <us8821$90p$4@dont-email.me> <20240306140214.0000449c@yahoo.com>
 <us9nib$dski$1@dont-email.me> <20240307000008.00003544@yahoo.com>
 <usc58s$10cls$1@dont-email.me> <20240307134401.00007aa2@yahoo.com>
 <uscmub$149j3$1@dont-email.me> <usf11f$1mk5l$1@dont-email.me>
 <usf63j$1nnsb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 8 Mar 2024 15:15:36 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="6e0a11c2f9940244b487580c0cc6ead4";
	logging-data="1863523"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+3O3uS7+mQ49lCNibJHHl1"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:14EHivHvGpSNRcqPmc4d42tY9eY=
In-Reply-To: <usf63j$1nnsb$1@dont-email.me>
Content-Language: en-GB
Bytes: 3135

On 08/03/2024 14:07, David Brown wrote:
> On 08/03/2024 13:41, Paavo Helde wrote:
>> 07.03.2024 17:36 David Brown kirjutas:
>>>
>>> CPython does use garbage collection, as far as I know.
>>>
>>
>> AFAIK CPython uses reference counting, i.e. basically the same as C++ 
>> std::shared_ptr (except that it does not need to be thread-safe).
> 
> Yes, that is my understanding too.  (I could be wrong here, so don't 
> rely on anything I write!)  But the way it is used is still a type of 
> garbage collection.  When an object no longer has any "live" references, 
> it is put in a list, and on the next GC it will get cleared up (and call 
> the asynchronous destructor, __del__, for the object).

Is that how CPython works? I can't quite see the point of saving up all 
the deallocations so that they are all done as a batch. It's extra 
overhead, and will cause those latency spikes that was the problem here.

In my own reference count scheme, when the count reaches zero, the 
memory is freed immediately.

I also tend to have most allocations being of either 16 or 32 bytes, so 
reuse is easy. It is only individual data items (a long string or long 
array) that might have an arbitrary length that needs to be in 
contiguous memory.

Most strings however have an average length of well below 16 characters 
in my programs, so use a 16-byte allocation.

I don't know the allocation pattern in that Discard app, but Michael S 
suggested they might not be lots of arbitrary-size objects.